Ch10: Layered Architecture Style#
Layered architecture（分層式架構），也稱為 n-tiered 架構，是最常見的架構風格。因為簡單、熟悉且低成本，它是大多數應用程式的預設選擇。
這種架構風格同時落入兩個反模式：architecture by implication（未明確選擇架構）和 accidental architecture（意外形成的架構）。如果開發團隊不確定要用什麼架構就「直接開始寫程式」，最終很可能就是 layered architecture。
Topology（拓撲結構）#
標準的 layered architecture 由四個層級組成：
- Presentation Layer — 處理所有使用者介面與瀏覽器通訊邏輯
- Business Layer — 執行與業務請求相關的商業規則
- Persistence Layer — 處理資料存取邏輯
- Database Layer — 資料儲存
在某些情況下，business layer 和 persistence layer 會合併（例如 persistence 邏輯直接嵌入 business component）。小型應用可能只有三層，大型應用可能有五層以上。
Figure 10.1: Standard logical layers within the layered architecture style
部署變體：
- 將 presentation、business、persistence 合併為單一部署單元，database 獨立
- Presentation 獨立部署，business + persistence 合併為另一單元
- 四層全部合併為單一部署（適合小型應用或嵌入式資料庫）
Figure 10.2: Physical topology (deployment) variants
每一層都是對特定工作的抽象，具有明確的角色與職責。這種 separation of concerns 使得各層的元件只需處理屬於該層的邏輯。
Layered architecture 是一種 technically partitioned（技術分區）架構，元件按技術角色（presentation、business）分組，而非按 domain 分組。因此，domain-driven design 的方法在這種架構下不太適用。
Layers of Isolation（層級隔離）#
每一層可以是 closed（封閉）或 open（開放）：
- Closed layer — 請求不能跳過該層，必須依序通過每一層
- Open layer — 請求可以繞過該層，直接到下一層
Layers of isolation（層級隔離）原則：某一層的變更不應影響其他層的元件。這要求主要請求流程中的層必須是 closed 的。
如果 presentation layer 可以直接存取 persistence layer，那麼 persistence layer 的變更就會同時影響 business layer 和 presentation layer，形成緊密耦合的架構。
Figure 10.3: Closed layers within the layered architecture
層級隔離的好處是可以獨立替換某一層。例如，可以將 JavaServer Faces (JSF) 的 presentation layer 替換為 React.js，而不影響其他層。
Adding Layers（新增層級）#
有時需要在架構中新增 open layer。例如：
- Business layer 中有共用的 shared objects（日期工具、字串工具、logging 等）
Figure 10.4: Shared objects within the business layer
- 架構決策要求 presentation layer 不得直接存取這些 shared objects
- 解決方案：新增一個 Services Layer（設為 open），放置所有 shared objects
- Business layer 可以選擇存取或繞過 services layer
- Presentation layer 因為 business layer 是 closed，所以無法觸及 shared objects
Figure 10.5: Adding a new services layer to the architecture
必須清楚文件化並溝通哪些層是 open、哪些是 closed，以及原因。未能正確記錄這些資訊，通常會導致緊密耦合、難以測試和部署的架構。
Architecture Sinkhole Anti-Pattern#
Architecture sinkhole anti-pattern（架構沉洞反模式）：請求在各層之間傳遞時，沒有任何商業邏輯處理，只是簡單的 pass-through。
例如：presentation layer 接收簡單的客戶資料查詢，依序傳到 business layer、persistence layer、database layer，但中間每一層都只是轉發，沒有任何計算或轉換。
判斷準則：80-20 法則
- 如果只有 20% 的請求是 sinkhole，屬於可接受範圍
- 如果 80% 的請求都是 sinkhole，表示 layered architecture 不是正確的選擇
另一種解決方式是將所有層設為 open，但 trade-off 是失去變更隔離的能力。
Why Use This Architecture Style#
適用場景：
- 小型、簡單的應用程式或網站
- 預算和時間非常有限的專案
- 架構師尚在分析業務需求、尚未確定最終架構風格時的起步選擇
注意事項：
- 隨著應用成長，maintainability、agility、testability、deployability 都會惡化
- 大型應用應考慮更模組化的架構風格
Architecture Characteristics Ratings#
| Architecture Characteristic | Rating |
|---|---|
| Partitioning type | Technical |
| Number of quanta | 1 |
| Deployability | 1/5 |
| Elasticity | 1/5 |
| Evolutionary | 1/5 |
| Fault tolerance | 1/5 |
| Modularity | 1/5 |
| Overall cost | 5/5 |
| Performance | 2/5 |
| Reliability | 3/5 |
| Scalability | 1/5 |
| Simplicity | 5/5 |
| Testability | 2/5 |
主要優勢：Overall cost 和 Simplicity
- 不具備分散式架構的複雜度，建置與維護成本低
- 但隨著規模成長，這些優勢會迅速遞減
主要弱點：
- Deployability（1/5） — 即使是三行程式碼的變更，也需要重新部署整個應用
- Testability（2/5） — 小變更通常伴隨大量其他變更一起部署，回歸測試成本高
- Elasticity / Scalability（1/5） — 單體部署限制了水平擴展能力
- Fault tolerance（1/5） — 單體部署中任一部分的記憶體錯誤會導致整個應用崩潰，加上 MTTR（mean-time-to-recovery）通常很高
