第 11 / 13 部 待錄

精煉與核心領域

《Domain-Driven Design 領域驅動設計》Podcast 準備稿：精煉與核心領域

書名： 領域驅動設計 Domain-Driven Design（Tackling Complexity in the Heart of Software） 作者： Eric Evans 系列： 啃一本大書（恩普拉氏） 公開標題建議： 啃一本大書｜Domain-Driven Design．Core Domain：你的軟體憑什麼值錢 (11/13) 涵蓋範圍： Part IV 第15章 精煉（Distillation）

背景速覽

接續上一集的 Bounded Context，這集講策略設計的第二把利器：Distillation（精煉/蒸餾）。核心問題是——大系統裡有太多不可或缺的元件，真正讓你的軟體與眾不同、值錢的那一小塊（Core Domain，核心領域）反而被淹沒、被忽視。精煉就是把精華從混合物裡分離出來的過程，讓最有價值的概念突顯，並指引團隊把最好的資源投在對的地方。

一句話重點

辨識出讓你的軟體真正值錢的 Core Domain，把它從一大堆支援性的通用模型裡分離、突顯出來，並把最強的人和最多的精力投在 Core——而不是讓頂尖開發者去做有趣但不關鍵的技術基礎設施。

值得討論的重點

1. Core Domain：商業資產所在

問題本質：大系統裡不可或缺的元件太多，真正的業務資產容易被遮蔽。Evans 點出一個殘酷的反諷——最頂尖的開發者往往被吸引去做技術基礎設施或好定義的問題（因為有趣、能累積可轉移的技能），而真正區分應用、讓它成為商業資產的 Core Domain，反而落到經驗較淺的人手裡。

解法：精煉模型、找出 Core Domain、提供容易區分它和支援性程式碼的手段。關鍵行動——把頂尖人才分配到 Core 並據此招募、在 Core 投入找深層模型和柔性設計、需要保密當競爭優勢的部分就是 Core、時間有限時優先重構影響 Core 的部分。

Core 的選擇取決於觀點：一個應用的 Core Domain，可能是另一個應用的通用支援元件（多數應用只需通用貨幣模型，但貨幣交易應用需要精細的貨幣模型當 Core）。

2. Generic Subdomains：把通用的東西分出去

模型裡有些部分增加複雜度卻不傳達專業知識——組織架構圖、會計模型這類在許多業務都用得到的東西。把這些「不是專案動機的內聚子領域」抽離到獨立 Module，不留任何你的專業特色，然後給它們比 Core 更低的開發優先序。

四種實作選項：現成方案、已發表的設計/模型、外包實作、自行實作。關鍵警告：Generic 不代表要追求 Reusable（可重用）——分離通用子領域的動機是「讓 Core 突顯」，不是「做可重用元件」，後者會違背精煉的初衷。Model 層級的重用（採用已發表的設計）往往比 code 層級的重用更有價值。

3. 兩個時區的故事

Evans 用兩個都花頂尖開發者數週處理時區問題的專案做對比：

  • 貨運排程專案：Core Domain 已成熟，確認需要時區功能後才指派短期承包開發者去研究實作，成功交付。
  • 保險理賠專案：Core Domain 還沒開發，就先派長期開發者（本該累積領域知識的人）去搞時區，需求不明還想全面通用化，結果程式碼從未被使用。

教訓：兩個專案都正確地把通用時區模型和 Core 隔離了，但保險專案在 Core 還沒成熟時就分散注意力。專案風險管理的原則：除非團隊技能已證明且領域很熟，第一版系統應基於 Core Domain 的某部分——因為 Core 是高風險的（常比預期難、且沒它專案不可能成功）。

4. 精煉的階梯：從便宜到昂貴

精煉技術由低到高（投入遞增、效果遞增）：

  1. Domain Vision Statement：一頁短文，闡述 Core Domain 及其價值（value proposition），最便宜。
  2. Highlighted Core：用蒸餾文件（3-7 頁稀疏內容）或在模型裡標記 Core 元素，幾乎不改設計。
  3. Generic Subdomains：重構分離通用子領域。
  4. Cohesive Mechanisms：把複雜的「怎麼算」封裝成獨立的輕量框架，讓模型專注「是什麼」（“A model proposes; a mechanism disposes.”）。
  5. Segregated Core：在程式碼層級把 Core 從支援角色中分離（成本高、要全團隊一起動）。
  6. Abstract Core：把最基本的概念抽成抽象類別/介面，表達元件間的主要互動（需要大幅重組）。

每一層磨得越細刀刃越鋒利，但承諾也越大。

注意事項

⚠️ 「Generic 不代表 Reusable」這條最反直覺、也最常被誤解。 工程師看到「通用子領域」就手癢想做成漂亮的可重用函式庫——但 Evans 說這違背精煉的動機。分離通用部分的目的是讓 Core 突顯，不是生產通用元件。如果你為了重用性而過度打磨通用子領域，你又把注意力從 Core 偷走了。這正是保險專案翻車的根因。

⚠️ Cohesive Mechanism（內聚機制）vs Generic Subdomain（通用子領域）容易混淆。 通用子領域是領域的一部分（代表團隊對某方面的理解，只是較不核心）；內聚機制不是領域，它是「為模型服務的計算引擎」（解決模型提出的棘手計算）。一句話分辨：「模型提出問題，機制處理問題。」組織架構圖是領域、圖論遍歷演算法是機制。

⚠️ Core Domain 幾乎買不到。即使有產業框架，客製軟體最大的價值來自對 Core 的完全掌控。如果一個框架過度約束你的 Core，要嘛你正在失去關鍵資產、要嘛你的 Core 邊界劃錯了、要嘛你的 Core 其實沒特殊需求（那就買現成的）。別把 Core 外包或框架化掉。

⚠️ Distillation Document 可以當流程工具：當開發者發現自己的變更需要同步改蒸餾文件，就代表他在動 Core 的根本，該跟團隊諮商。Core 外的變更則可以自由整合。但前提是文件要絕對精簡、聚焦中心抽象，否則沒人維護、沒人讀。

專家補充

💡 「把最強的人放在 Core Domain」這條，是 DDD 裡最容易被組織違反、後果也最嚴重的一條。現實中發生的往往相反——最強的人被抽去做平台、做框架、做基礎設施（因為那「有挑戰性」），Core 業務邏輯丟給菜鳥或外包。Evans 早在 2003 就警告這是「為失敗做準備」。這條會在第 13 集（全書收束）以「架構團隊不該抽走所有最聰明的人」的形式再次出現，是 Evans 一以貫之的執念。

💡 Core Domain 的概念後來在 Vernon 和社群手裡演化成 Core / Supporting / Generic Subdomain 的三分法，配上「優先序矩陣」（按業務差異化程度 × 複雜度，決定哪些自建、哪些買、哪些外包）。這是策略 DDD 做投資決策的實用工具。創業者尤其該懂：你的 Core Domain 就是你的護城河，把資源砸在那裡，其他全部買現成的。

💡 Domain Vision Statement（一頁說清楚「我們的核心領域是什麼、憑什麼值錢」）其實不只是技術文件——它幾乎就是產品的 value proposition。能不能用一頁紙講清楚你的軟體核心價值，是個很好的試金石。如果寫不出來，可能你自己都還沒想清楚 Core 在哪。這對工程師、PM、創業者都適用。

討論問題

🎙️ 開場鉤子：「你的軟體有上百個功能，但讓它真正值錢、別人抄不走的，可能只有其中一小塊。Evans 叫它 Core Domain。而最諷刺的是——你最強的工程師，現在很可能正在做那塊以外的東西。」

🎙️ 自問自答：「怎麼判斷什麼是 Core Domain？」——問三件事：哪部分是你的競爭優勢、需要保密？哪部分如果做爛了專案就失敗？哪部分買不到、必須自己掌控？這三個交集，就是你的 Core。

🎙️ 帶走的一題：「試著用一頁紙寫出你產品的 Domain Vision Statement——你的核心領域是什麼、它憑什麼值錢。如果寫不出來，那就是個警訊：你可能還沒搞清楚自己的護城河在哪。」

更大範圍關聯

  • 策略設計的資源分配維度：Bounded Context（EP10）回答「怎麼切」，Distillation（本集）回答「切完之後，力氣往哪投」。兩者是策略設計的兩條正交軸線。
  • 連到創業 / 產品策略：Core Domain 就是軟體的護城河。「Core 自建、Supporting 看情況、Generic 買現成」是技術投資決策的黃金法則，對創業者尤其關鍵——別在通用問題上燒掉本該投在差異化上的資源。
  • 連到 Conway / 組織設計：「最強的人放 Core」這條，在第 13 集會升級成「架構團隊不該抽光最聰明的人」。Evans 反覆對抗「把菁英抽離應用開發」的組織傾向。
  • 連到柔性設計：Cohesive Mechanism（把「怎麼算」封裝成框架、讓模型專注「是什麼」）直接延續第 8 集 Shares Math「找出領域裡的數學、抽出來」的思路。精煉到極致就是讓 Core 用宣告式語言運作。
  • 務實的買 vs 建：四種實作選項（現成/已發表設計/外包/自建）是工程經濟學的具體應用，呼應「不是每個東西都該自己寫」的成熟態度。

錄製建議

  • 建議時長：約 24-26 分鐘。配比：Core Domain 與「頂尖開發者被吸去做基礎設施」的反諷約 8 分、Generic Subdomains 與「Generic 不等於 Reusable」約 6 分、兩個時區的故事約 5 分、精煉階梯（六層）約 6 分。
  • 討論策略：用「你最強的工程師現在在做什麼」這個尖銳問題開場，幾乎每個團隊都中招。兩個時區的故事是這集最好的敘事素材（同樣的問題、不同的時機、相反的結果），務必完整講。精煉階梯六層別逐一細講，抓「從一頁 Vision Statement 到 Abstract Core，投入和效果一起遞增」的框架即可。
  • 這集很適合把鏡頭從「工程」拉到「策略/商業」——Core Domain 本質是個商業概念。對創業者、PM 背景的聽眾，這集最有跨界吸引力。連到「護城河」「value proposition」會很有共鳴。