策略和層級 (Policy and Level)#

title: “Ch19: 策略與層級 (Policy and Level)” weight: 19

19. 策略與層級 (Policy and Level)#

軟體系統本質上就是一組**策略（Policy）**的集合。 實際上，電腦程式就是對輸入資料進行轉換並產生輸出資料的一種詳細描述。

一、策略的重組#

為了建立良好的架構，我們需要將這些策略分解為不同的元件。

• 原則： 根據 SRP（單一職責原則） 和 CCP（共同封閉原則）。
• 作法： 將那些「為了相同原因而同時變化」的策略，分組在同一個元件中。
• 目標： 將這些元件重組成一個有向無環圖（DAG）。

二、什麼是「層級 (Level)」？#

在架構圖中，我們常說「高層依賴」或「低層實作」，但到底什麼是高低之分？ Uncle Bob 給出了一個嚴格的定義：

層級的定義： 「層級（Level）就是距離輸入與輸出的遠近。」 (Level is strictly defined as the distance from the inputs and outputs.)

• 低層級（Low Level）： 負責管理輸入與輸出的策略。因為它們直接接觸 I/O（如讀取 SQL、渲染 HTML），所以距離最近。
• 高層級（High Level）： 距離輸入與輸出最遠的策略。它們是核心業務邏輯，完全不關心資料是從哪裡讀進來，或要顯示到哪裡去。

三、依賴關係的規則#

有了層級的定義，架構規則就變得非常清晰： 「原始碼的依賴關係，應主要指向高層級的策略。」

$$低層級 \rightarrow 依賴 \rightarrow 高層級$$

為什麼這樣設計？#

這與變化的頻率和原因有關：

1. 低層級（I/O 相關）： 變化非常頻繁（如：更換 UI、升級資料庫驅動、改變報表格式）。且變化的原因通常較為瑣碎。
2. 高層級（業務核心）： 變化較少（除非商業模式改變）。變化的原因通常較為重大。

結論： 我們希望「頻繁變化」的組件去依賴「穩定」的組件。 讓依賴關係指向高層級（遠離 I/O），就能確保當 UI 或資料庫（低層級）變更時，核心業務邏輯（高層級）完全不受影響。

小結： 架構設計的精隨，就是將系統中的策略依照「距離 I/O 的遠近」進行分層，並嚴格限制依賴方向只能由外（I/O）向內（核心）流動。