「軟體系統是策略(Policy)的陳述。電腦程式是將輸入轉換為輸出的『策略的詳細陳述』」

「會因著相同的原因在相同時間變化的策略，處在同一層級，並且會隸屬於同一個元件。架構的藝術通常涉及到將元件重組成一個有向無環圖(DAG)」

取自: Clean Architecture (p.153 & p.154)

CH19: 策略和層級

• 好的架構...

層級 (Level)

• 「層級」的嚴格定義是 「與輸入及輸出的距離」
  • 離系統的輸入和輸出越遠，策略的層級就越高
  • 管理輸入和輸出的策略，是系統中最低層級的策略

經典案例：加密程式

UML...

// code...

CH20: 業務規則 (Business Rules)

「業務規則有著幾種不同的類型，嚴格地說，它是賺取或節省商業資金的規則或程序。非常嚴格地說，不論是否在電腦上，即便是手動執行這些規則，它們都可以賺取或節省商業資金」

「業務規則應該保持質樸的狀態，不受 UI 或 DB 等基礎問題所影響。它們很少會關注誰 Plugin 進來。業務規則應該是系統中最獨立、最可複用的程式碼」

取自: Clean Architecture (p.157 & p.161)

• 關鍵業務規則
• 關鍵業務資料

P.S. 作者關於 Business Rules 的定義馬上讓我思考到非營利組織 (例如教育平台)，它們的核心業務規則又是什麼呢? 我想，也許就是一個領域中最核心的 Know-how 吧。又或許可以作者的另一句話來概括：

「業務規則是軟體系統存在的原因，它們是核心功能。它們是程式中的寶石」

實體 (Entity)

(TODO: 換一張圖，或自製)

...

• 補充: 有關 Entity 實作與細節，筆者還是想再推一次這系列鐵人文 － DDD 戰術設計： Entity 概念與實作

使用案例 (Use Cases)

(TODO: 自己製圖..., 把兩張合併...)

請求與回應模型 (Request and Response Models)

Reference

A UML class model defining business domain
軟體需求分析與塑模
Use Cases and Business Rules: Can They Work Together?