《Domain-Driven Design 領域驅動設計》Podcast 準備稿：導論與消化知識
書名： 領域驅動設計 Domain-Driven Design（Tackling Complexity in the Heart of Software） 作者： Eric Evans 系列： 啃一本大書（恩普拉氏） 公開標題建議： 啃一本大書｜Domain-Driven Design．軟體的核心是領域，不是技術 (1/13) 涵蓋範圍： 全書導論 ＋ Part I 開場 ＋ 第1章 消化知識（Crunching Knowledge）
背景速覽
這是「啃一本大書」開啃 DDD 的第一集。《Domain-Driven Design》(2003) 是 Eric Evans 寫的領域建模奠基經典，被工程界暱稱為「藍皮書」。它厚、難讀、概念密度高，但奇怪的是——它在 2003 出版、卻在十幾年後的微服務時代「重新爆紅」。這一季我們要花 13 集把它啃透。第一集先講「DDD 到底想解決什麼問題」，再進到第1章：一個工程師完全不懂硬體、卻要做出 PCB 設計工具的真實故事，示範什麼叫「消化知識」。
一句話重點
軟體真正的複雜度不在技術，而在業務領域本身；DDD 的起手式不是寫程式，而是開發者和領域專家一起「消化知識」——透過反覆對話、原型、實驗，把散落在許多人腦中的領域知識，提煉成一個能驅動軟體設計的模型。
值得討論的重點
1. DDD 真正的核心，不是 Entity、Repository 那些戰術模式
先把這季的定錨立起來：很多人提到 DDD，腦中浮現的是 Entity、Value Object、Repository、Aggregate——這些「戰術模式」。但 Evans 寫這本書真正的野心，是戰略：統一語言（Ubiquitous Language）和限界上下文（Bounded Context）。戰術模式只是 Part II 一小塊；全書最有價值的洞見在 Part III、IV。我會在這季反覆提醒：只學了 Entity/Repository 卻漏掉戰略，等於只學了 DDD 的皮。
2. 軟體的複雜度，藏在「領域的核心」
書名副標是「Tackling Complexity in the Heart of Software」——對付軟體核心的複雜度。Evans 的前提：對大多數企業軟體來說，最難的不是用什麼資料庫、什麼框架，而是「這門生意到底怎麼運作」。航運的責任轉移、銀行的聯貸份額、保險的理賠規則——這些業務邏輯才是讓軟體真正困難的地方。把技術做漂亮但領域模型一團糟，軟體照樣失敗。
3. 消化知識是「協作」，不是「需求訪談」
第1章的 PCB 故事很生動：Evans 對電子硬體一竅不通，卻要在期限內交付。前幾次會議很挫折——領域專家想直接告訴他「軟體該做什麼」（讀檔、排序、出報表），但這種單向的需求傳遞做不出好東西。轉機是他抓住反覆出現的 Net（線路導體）這個詞，開始用物件互動圖跟專家一起走情境，專家不斷糾正術語（components 其實是 Component Instance、Ref-des 只是某工具的稱呼），模型就在對話中長出來。
關鍵對照——兩種失敗模式：
- 瀑布式：業務專家 → 分析師 → 程式設計師，知識單向流動、一路流失。
- 無抽象的迭代：開發者只問「下一步要做什麼」，做出堪用軟體，但永遠到不了「新功能自然從舊功能推導出來」的境界。
- 消化知識：開發者被迫學懂業務原則，專家被迫把知識提煉成精確概念，雙向學習，模型持續變深。
4. 知識豐富的模型：Overbooking 的例子
別把建模講成「找名詞」。Evans 用航運超額訂艙（overbooking）示範：需求文件裡一句「允許 10% 超額訂艙」，第一版被寫成 makeBooking 裡的一個 guard clause——業務規則被藏在程序碼裡，專家看不懂、開發者也對不上需求。改進的設計把它抽成一個 Overbooking Policy 物件（STRATEGY 模式的應用）。差別在：現在所有人都知道「超額訂艙是一條獨立且重要的業務規則」，而且開發者可以把程式碼拿給專家看、關閉回饋迴路。模型不只裝資料，它捕捉了規則與行為。
注意事項
⚠️ 這本書很厚、很難讀，這點要誠實跟聽眾講。它不是睡前讀物，概念層層疊疊、案例橫跨銀行/航運/化學倉儲。我的建議是：先抓骨架（戰略思想）、再回頭補戰術細節。這也是為什麼我把這季排成 13 集、慢慢啃。
⚠️ 別把「消化知識」浪漫化成「跟專家聊聊天就有模型」。Evans 自己也說，這是一場探索，你無法預知終點——PCB 專案裡那個 Probe Simulation 功能最後還被砍掉了。但他強調：早期的工作仍然關鍵，因為它啟動了消化知識的過程、建立了共享語言。探索之旅必須有起點。
專家補充
💡 為什麼 2003 的書會在微服務時代爆紅？因為微服務逼著大家面對一個老問題：「系統到底該怎麼切？」而 DDD 的 Bounded Context 正好給了切分的理論依據。我們這季會一路鋪陳到第 10 集講清楚這條線。第一集先埋個伏筆：你現在聽到的「消化知識、統一語言」，是後面所有戰略設計的地基。
💡 Evans 這本書的寫法本身很「模式語言」（pattern language）——受 Christopher Alexander 建築模式的影響很深（全書最後一章還直接引用 Alexander 批判 Master Plan）。所以你會看到大量「粗體模式名 + 因此（Therefore）+ 做法」的結構。讀的時候抓那些大寫的模式名（UBIQUITOUS LANGUAGE、BOUNDED CONTEXT），它們是這套語言的詞彙。
💡 業界常見的搭配是「Evans 講思想、Vernon 講落地」。Vaughn Vernon 的《Implementing Domain-Driven Design》（紅皮書）和《Domain-Driven Design Distilled》（薄薄一本）才是教你怎麼動手寫的。Evans 這本給的是「為什麼」和「世界觀」，比較像哲學書。聽眾如果讀 Evans 覺得抽象到抓不住，可以拿 Vernon 當實作對照。
討論問題
🎙️ 開場鉤子：「你有沒有接過一個專案，技術都對、框架都新、但就是越做越亂、業務規則散得到處都是？DDD 說，那是因為你跳過了最重要的一步——沒有真正搞懂這門生意。」
🎙️ 自問自答：「需求訪談跟消化知識差在哪？」——需求訪談是專家單向告訴你「做什麼」；消化知識是你跟專家一起把領域重新理解一遍，連他自己可能都沒想清楚的概念，在對話中被逼出來。
🎙️ 帶走的一題：「下次跟業務方開會，試著不要急著問『這功能要怎麼做』，改成抓他反覆講的某個詞，問他『這個詞到底是什麼意思』——看會挖出什麼。」
更大範圍關聯
- 領域建模的奠基經典：DDD 之於領域建模，地位類似《重構》之於程式碼改善、GoF 之於物件設計。它定義了一整套後人沿用至今的詞彙。
- 程式碼設計三本：DDD ＋ Design Patterns（GoF）＋ Refactoring（Fowler），是這季所屬「程式碼設計三本」主題的核心三角（見 [軟體工程領域切分藍圖] §5）。怎麼搭讀我會在最後一集收束時講清楚——這集先記住：DDD 給世界觀、GoF 給零件、Refactoring 給手法。
- 思想源頭：Evans 的「模式語言」寫法直接承襲 Christopher Alexander 的建築模式理論；「消化知識」的精神則和 Fred Brooks《人月神話》的「概念完整性」遙相呼應。
- 微服務的前置知識：本書是 Bounded Context 的發源地，而 Bounded Context 後來成為微服務切分的理論基礎。這條線會貫穿整季，第 10 集正式接上。
錄製建議
- 建議時長：約 22-25 分鐘。配比：導論＋為什麼啃 DDD 約 8 分（一定要把「戰略 vs 戰術」這條定錨講清楚）、消化知識約 14 分（PCB 故事和兩種失敗模式是主菜，Overbooking 例子收尾）。
- 討論策略：這是整季起手集，務必花 1-2 分鐘介紹「啃一本大書」是什麼、為什麼選 DDD、這 13 集打算怎麼走，建立系列感。中段用 PCB 故事的「挫折→抓住 Net 這個詞→模型長出來」當敘事主線，聽眾最有畫面。結尾埋下戰略設計的伏筆，讓人想追下一集。
- 反覆強調一句話：DDD 的核心是語言和邊界，不是 Entity 和 Repository。 這句會是整季的定海神針。