一本講 Application Architecture Patterns 如何運用在 Enterprise Application 的大作，作者 Martin Fowler 出過不少軟體開發的書，其中最重要的就數 重構 Refactoring (有中譯) 了，另外還有暢銷書 UML Distilled 、 談 OOA 範式的 Analysis Patterns ( Design Patterns 一書是談OOD層次的範式 )、跟 Beck合著的 Planning Extreme Programming (有中譯)等。
這本書內容談 EA 的 Layers、如何組織 Domain (Business) Logic、物件與關聯資料庫的對應處理、Web Presentation、並行處理 Concurrency、處理 Session State 在 stateless 的環境、分散式應用程式的策略等。
章節分兩部份，前8章給你依序看，簡介各個範式讓你有個大局觀，後大半9~18章則是各個 pattern 的詳細內容。第0章是簡介，談一些名詞 Architecture, Exterprise Applications,Performance,Patterns 等。
Architecture
從高觀點來看系統各部份，決定哪些是很難改變的部份。還有架構是主觀的概念，因此某些 patterns 其實也可以看做一種 architectural 。
Enterprise Applications
又叫做 information systems，因為有很多資料跟很多處理。有幾個特點如下。
- persistent data 要保存很久的資料
- a lot of data 一大堆資料(GB等級)
- access data concurrently 一堆人會同時存取
- a lot of user interface screens 一大堆使用者畫面(上百個很普通)
- integrate with other enterprise applications 常和其他 EA 一起運作 (這部份本書不涵蓋，你要看 Enterprise Integration Patterns 才有)
- conceptual dissonance 處理資料觀念上及語意不一致的情況，但仍必須能同步運作。如不同部門看”一個人”的定義也許會不同。
- complex business “illogic” 處理複雜的商業邏輯
Performance
在做 persormance 決策前，你得真的在你的設定上測過才有意義，比較調整前後的差異才知道有沒有用，不然你會把code改難懂了卻沒有實質幫助 :p
- Response time 完成一項需求的時間
- Responsiveness 第一反應時間，如出現 progress bar
- Latency 至少延遲時間，如 remote call 的網路傳輸延遲
- Throughput 一定時間內可以幹多少事
- Performance 看你喜歡指 throughput 或 response time (若這兩個有矛盾，你就要小心定義了)。另外從使用者觀點看，加快 Responsiveness 比 Response time 更重要，即使他是增加 Response time 的。
- Load 系統負重程度
- Load sensitivity 當 Load 增加時，Response time 增加的敏感程度
- Efficiency Performance除resource
- Capacity 系統最大有用的 throughput 或 load
- Scalability 系統可由增加資源(通常是硬體)來增加 performance 的程度。對EA來說有意思的是，通成建造一個有 Scalability 能力的系統比增加 capacity 或 efficiency 更重要，因為隨著你要增加 throughput，你只要花個錢就達到效果反而是比較經濟，畢竟 server 硬體比 programmer (努力改code增加效能)還便宜 :p作者打個例子，假設 A 容量 20人，B容量40人。應該是A比較有 efficiency 吧。但是多買一台 server 時，A可以處理35人，B可以處理50人。這時候你算算看 scalability，如果你有上千人要處理，哪種比較好 :p
Patterns 是描述一個重複出現的問題並描述解法，當然 patterns 還是有限制的，你還是得多想想並修改才能適時的應用。
後記: 關於 EA 的 Patterns ，找到一個站詳細分類了。
發佈留言