第 12 / 13 部 待錄

大尺度結構

《Domain-Driven Design 領域驅動設計》Podcast 準備稿：大尺度結構

書名： 領域驅動設計 Domain-Driven Design（Tackling Complexity in the Heart of Software） 作者： Eric Evans 系列： 啃一本大書（恩普拉氏） 公開標題建議： 啃一本大書｜Domain-Driven Design．大系統怎麼維持可理解 (12/13) 涵蓋範圍： Part IV 第16章 大尺度結構（Large-Scale Structure）

背景速覽

策略設計的第三把工具：Large-Scale Structure（大尺度結構）。就算你已經用 Module 分解、用 Bounded Context 隔離、用 Distillation 聚焦了，當系統大到一定程度，還是會迷路——Module 太多不知道功能在哪、新類別不知道放哪、每個人各做各的合理決策拼起來卻難以理解。大尺度結構是一套橫跨整個系統的高階概念規則，讓人即使不懂某部分細節，也能知道它在整體裡的位置。這集偏抽象、偏「大系統的組織哲學」，是 Part IV 最思辨的一章。

一句話重點

給整個系統一套「大筆觸」的組織語言（如責任分層、系統隱喻、知識層級），讓人不深入細節也能理解每個部分的角色——但這套結構必須隨理解演進（Evolving Order）、保持最小，而不是前期一次性凍結的架構。

值得討論的重點

1. Evolving Order：演進的秩序

開場最重要的原則。許多團隊為了避免混亂，前期就施加架構約束——但 Evans 警告這很危險：過早凍結的架構會在需求變化、理解加深時變成束縛，開發者為了配合架構而把應用做笨（dumbing down），或乾脆繞過它。問題不在「有沒有指導規則」，而在規則的僵化程度與來源。

所以核心原則：讓大規模概念結構隨應用演進，途中可能完全改變結構類型（從隱喻改成分層都行）。別用全域規則過度約束那些需要在地知識才能做的詳細決策。大尺度結構是可選的（不像 Context Map 是必要的），只有好處大於代價、且找到合適結構時才施加。而且「少即是多」——找能解決已浮現問題的最小集合即可。

2. 五種結構模式（由鬆到緊）

  • System Metaphor（系統隱喻）：來自 XP，用具體類比帶來秩序（如「防火牆」隱喻塑造了整個產品類別）。但所有隱喻都帶包袱，要隨時準備在它造成阻礙時捨棄。Evans 還順帶說「Naive Metaphor」（用領域模型本身當隱喻）這詞該廢除——成熟的領域模型經過多次消化知識迭代，絕非「天真」。
  • Responsibility Layers（責任分層）：本章篇幅最長的核心。當你深入領域，會看到某些概念發生在其他元素的背景之上、而背景元素以不同速率變化——這種自然分層暗示了責任層。常見的層：Potential（潛力/資源，「可以做什麼」）、Operations（營運，「正在做什麼」）、Decision Support（決策支援，「該做什麼」）、Policy（政策，「規則是什麼」）、Commitment（承諾）。
  • Knowledge Level（知識層級）：來自 Fowler，把模型分成 Operations Level（基本物件）和 Knowledge Level（描述/約束基本模型結構行為的物件，可由超級使用者自訂）。員工薪資/退休金的例子——既不能寫死、又不能完全放開，用 Knowledge Level 讓使用者在規則約束下自訂。
  • Pluggable Component Framework（可插拔元件框架）：最緊、最難，只在模型非常成熟、同領域已做過多個應用後才該出現（如半導體業的 SEMATECH CIM Framework）。

3. 責任分層的發現過程（貨運系統範例）

Evans 用貨運系統詳細示範責任層怎麼「被發現」而非「被規劃」。團隊注意到：可以不提貨物就討論運輸排程，但很難不提運輸工具就討論貨物追蹤——這暗示了分層。第一輪分出 Operations 和 Capability（Potential）兩層；第二輪發現 Router 不屬於當前營運、而是幫助做決策，於是加入 Decision Support 層；過程中還發現 Transit Leg 上的「is preferred」屬性是政策而非能力，重構模型把 Route Bias Policy 獨立出來。重點：好的大尺度結構往往會推動模型朝闡明其含義的方向演化。

4. 結構如何影響後續設計

一旦採用大尺度結構，後續所有設計決策都要納入它。Evans 用「危險品路由」示範：直覺設計讓 Cargo（Operations 物件）依賴 HazMat Policy（Decision Support 物件）——違反分層。符合分層的做法是讓 Router 在搜尋前先收集適當的政策。Evans 誠實地說：兩種設計各有優缺點，但如果全專案以一致方式做決策，整體的可理解性遠比個別設計的微小取捨更有價值。如果結構逼出太多彆扭設計，依 Evolving Order 該修改或捨棄它。

注意事項

⚠️ 這章最容易被誤讀成「DDD 也支持前期大架構」——恰恰相反。 Evans 整章都在對抗「象牙塔架構」。大尺度結構的精神是 Evolving Order（演進的秩序），不是 Master Plan。它是「可選的、最小的、隨理解演進、可以整個換掉的」。如果你把它當成「前期定死的企業架構」，你就完全讀反了。這條一定要講清楚，否則會給聽眾錯誤印象。

⚠️ 層數要少——超過四五層就笨重。太多層無法有效講故事，大尺度結構原本要解決的複雜度會以新形式回來。Evans 的話：大尺度結構必須被狠狠地精煉。

⚠️ Knowledge Level 要謹慎用。如果它變複雜，系統行為對開發者和使用者都會難以理解，配置它的使用者最後可能需要程式設計師的技能。只在「客製化至關重要、且否則會扭曲設計」的地方用。而且別用程式語言的 reflection 來實作領域層的 Knowledge Level——那些 meta-object 描述的是語言構造，不是領域。

⚠️ Pluggable Component Framework 不該是專案首先、甚至第二個採用的結構。最成功的案例都是在多個專門應用完整開發之後才出現的。它會凍結 Core 的持續精煉、限制應用的多樣性。別一開始就想做框架。

專家補充

💡 這章在現代讀，最有共鳴的其實是「Restructuring Yields Supple Design」那段——Evans 觀察到有大尺度結構的設計通常比沒有的更容易轉換，即使是從一種結構換成另一種。他用皮夾克類比：新夾克僵硬，穿久了肘部會彎、肩膀會鬆、最後變得柔韌舒適。經過多次正確轉換的模型也一樣，知識被嵌入、變化軸線被識別並變得靈活。這呼應了第 8 集的柔性設計——結構和柔性是互相成就的。

💡 責任分層（Potential/Operations/Decision Support/Policy）這套，今天看很像「事件驅動架構」和「CQRS」的分層直覺——Operations 層產生事件、Decision Support 層消費事件做分析、Policy 層約束行為。Evans 的「不同層以不同速率變化」也正是現代「把快變和慢變的東西分開」（如把易變的業務規則抽成可配置的 Policy）的思路。這章的抽象框架，在微服務和事件驅動的時代有了具體載體。

💡 整章貫穿一個張力：一致性 vs 靈活性。更緊的結構增加一致性、讓設計好讀、推開發者往好設計走；但過緊會剝奪靈活性，尤其在跨 Bounded Context、異質系統時。Evans 的立場很清楚——抵抗建框架、嚴格規範的誘惑，大尺度結構最重要的貢獻是「概念連貫性和對領域的洞察」，每條規則都該讓開發更容易，而不是更難。這是對「過度工程化的企業架構」的長期警告。

討論問題

🎙️ 開場鉤子：「系統大到一個程度，你會發現一個怪現象——每個人做的決策單獨看都合理，但拼起來就是沒人看得懂。大尺度結構想解決的就是這個：給整個系統一套『大筆觸』的語言。但 Evans 有個但書——這套結構絕不能是前期定死的。」

🎙️ 自問自答：「大尺度結構和『前期企業架構』差在哪？」——前期企業架構是 Master Plan，定死了、僵化了、逼大家配合；大尺度結構是 Evolving Order，隨理解演進、可以整個換掉、保持最小。一個是極權秩序，一個是有機秩序。

🎙️ 帶走的一題：「你公司有沒有那種『三年前定的架構規範，現在大家都在偷偷繞過』的東西?那就是 Evans 警告的『過早凍結的架構』。問問自己：它還在幫你，還是已經變成枷鎖？」

更大範圍關聯

  • 策略設計的第三維：Bounded Context（怎麼切）、Distillation（力氣往哪投）、Large-Scale Structure（大系統怎麼維持可理解）——這集補上策略設計的最後一塊。三者下一集會被 Evans 綜合起來。
  • 連到事件驅動 / CQRS：責任分層（Operations 產事件、Decision Support 做分析、Policy 約束）的直覺，在現代事件驅動架構和 CQRS 裡找到了具體載體。「快變和慢變的東西分開」是兩者共同的智慧。
  • 對抗象牙塔架構：Evolving Order 是 DDD 對「前期大架構 / 企業架構師畫藍圖」的長期反擊。它和敏捷的「演進式架構」（Evolutionary Architecture，後來 Neal Ford 等人寫成專書）同源。
  • 連到柔性設計：「有結構的設計更容易轉換」（皮夾克類比）呼應第 8 集——結構和柔性互相成就，知識在反覆轉換中被嵌入模型。
  • 連到 Clean Architecture / 分層：責任分層和 Uncle Bob 的架構分層都在問「依賴該往哪個方向、什麼東西該獨立於什麼」。但 DDD 的層是按領域責任分（業務決策），不是按技術關注分。

錄製建議

  • 建議時長：約 24-26 分鐘。配比：Evolving Order 約 6 分（最重要、要把「不是前期大架構」講透）、五種結構模式約 8 分、責任分層的發現過程（貨運範例）約 7 分、結構如何影響設計 + 一致性 vs 靈活性張力約 5 分。
  • 討論策略：這章偏抽象，最大風險是聽眾覺得「離我很遠」。對策：用「每個人決策都合理、拼起來沒人懂」這個普遍痛點開場，再用「三年前定的、現在大家偷偷繞過的架構規範」把 Evolving Order 拉到聽眾自己的經驗。五種模式別平均用力，重點放在 System Metaphor（最鬆、好懂）和 Responsibility Layers（核心），Knowledge Level 和 Pluggable Framework 點到即可（它們較罕見）。
  • 全程扣住「這不是前期大架構，是演進的秩序」——這是這章最容易被誤讀、也最重要的訊息。連到敏捷的演進式架構會讓現代聽眾有共鳴。下一集是全書最終回，可以預告「Evans 要把 Bounded Context、Distillation、Large-Scale Structure 三把工具綜合起來，給策略設計六條原則收尾」。