《Domain-Driven Design 領域驅動設計》Podcast 準備稿：統一語言 Ubiquitous Language
書名： 領域驅動設計 Domain-Driven Design（Tackling Complexity in the Heart of Software） 作者： Eric Evans 系列： 啃一本大書（恩普拉氏） 公開標題建議： 啃一本大書｜Domain-Driven Design．統一語言：團隊講同一種話 (2/13) 涵蓋範圍： Part I 第2章 溝通與語言的使用（Communication and the Use of Language）
背景速覽
這一集進到 DDD 兩大支柱之一：Ubiquitous Language（統一語言／無所不在的語言）。如果整本書只能記一個概念，很多人會選這個。第2章談的是：當團隊沒有共同語言時，溝通會付出多麼隱形又巨大的代價；以及如何讓領域模型成為團隊語言的骨幹，讓開發者、領域專家、程式碼三方講同一種話。
一句話重點
讓領域模型本身成為團隊的共同語言——開發者之間、開發者與專家之間、甚至程式碼裡，都用同一套詞彙；這個語言要無所不在（ubiquitous），而且語言的每一次改變，就是模型的一次改變。
值得討論的重點
1. 語言分裂的代價：到處都在「翻譯」
Evans 先描述沒有共同語言的慘狀：開發者要把技術概念翻譯給專家、專家要在開發者和其他專家之間轉譯、開發者之間也要互相翻譯。每一次翻譯都在扭曲模型概念，導致破壞性的重構。更糟的是，最精確的領域表達往往只出現在某次短暫的口頭對話裡，講完就消失了，沒被沉澱進模型或程式碼。語言一分裂，消化知識就變得貧血。
2. 統一語言：模型當骨幹
解法不是找「最大公因數」式的妥協語言，而是有意識地把領域模型當成語言的骨幹。詞彙來自：類別名稱、重要操作名稱、模型裡明確表達的規則、高層組織原則（如 Context Map）、團隊常用的模式名。模型的關聯成了語言的組合文法。然後這套語言要被用在所有地方——討論需求、寫計畫、專家彼此溝通、寫進程式碼。Evans 的金句：語言使用得越普遍，理解的流動就越順暢。
3. 語言改變 = 模型改變
這是最容易被忽略、卻最關鍵的一條：當團隊發現某個說法很笨拙、要換個講法，或發現語言有缺口、需要新詞——這些都是模型要改變的訊號。語言的演進會逼出模型的弱點：嘗試替換笨拙用詞 → 發現語言缺口 → 新詞進入討論 → 認定模型要改 → 更新類別圖、重新命名、甚至改行為。領域專家該反對不恰當的術語，開發者該注意會絆倒設計的模糊與不一致。
4. Cargo Router 兩種對話，與「大聲建模」
Evans 用兩段對話對照。情境一沒有好模型，開發者只能講「刪掉 shipment 表那些列、把 origin/destination 傳給 Routing Service、在 Cargo 放個 Boolean……」——冗長、技術導向、容易誤解。情境二有了豐富模型，同樣需求變成：「改變 Route Specification 任何屬性時，丟掉舊 Itinerary、請 Routing Service 依新 Spec 產生新的。」——精簡、準確。
然後他丟出一個很實用的技巧：Modeling Out Loud（大聲建模）。人類對口語有天賦，模型的粗糙邊緣很容易「聽」出來。他示範一句話從「給 Routing Service 一個 origin、destination……塞進資料庫」一路精煉到「A Routing Service finds an Itinerary that satisfies a Route Specification.」——當你能用模型的詞彙乾淨地說出一個場景，模型就成熟了。
注意事項
⚠️ 技術人常有個衝動：想「保護」業務專家、不讓他們碰模型，理由是「太抽象」「他們不懂物件導向」。Evans 直接反駁：那你怎麼知道你的抽象是對的？如果資深領域專家看不懂你的模型，那是模型有問題，不是專家的問題。 這條很反直覺，但很重要——好的領域模型，專家應該要看得懂、而且能用它指出你哪裡錯了。
⚠️ 語言的多元性有時是必要的（開發者有技術術語、使用者有業務行話），但 Evans 強調：語言的分界線不該畫在「開發者 vs 專家」之間。 這些方言可以是語言的延伸，但不該對同一個領域概念有兩套互相打架的詞彙。
⚠️ 別把統一語言做成「一份詞彙表文件」就交差。Evans 對文件的態度很務實：判斷文件有沒有用，看它有沒有真的影響到大家口頭講的語言和程式碼。如果文件跟不上語言的演進、被晾在一邊，不如歸檔——靠意志力維護沒人看的文件是浪費。
專家補充
💡 統一語言為什麼是 DDD 最被低估的部分？因為它聽起來「太軟」——不就是大家講話一致嗎？但它其實是整套方法的引擎。後面所有戰術模式（Entity、Service……）和戰略模式（Bounded Context）能不能運作，都取決於團隊有沒有一套活的共同語言。Bounded Context 的定義甚至就是「統一語言成立的範圍」。所以這集是後面所有集數的地基。
💡 一個落地技巧：用統一語言寫 use case 和驗收測試（acceptance test）。當測試斷言裡用的是 aRoutingService.findItinerary(routeSpec) 這種領域詞彙、而不是 SQL 和 Boolean，這份測試本身就在維護統一語言、而且專家有機會讀懂它。這也呼應了後來 BDD（行為驅動開發）和 Gherkin 的「given-when-then 用業務語言寫」的思路。
💡 Evans 區分了兩種模型：一個是支撐實作的「主模型」，另一個是純教學用的 Explanatory Model（解釋性模型）。後者可以用專家慣用的視覺隱喻、不必是物件模型、甚至最好別用 UML（免得讓人誤以為是設計）。這提醒我們：傳達領域知識的圖，和驅動程式碼的圖，目的不同、可以長得不一樣。「模型不等於圖表，程式碼才是設計細節的儲存庫。」
討論問題
🎙️ 開場鉤子：「你有沒有發現，同一個詞，業務說的跟工程師寫在 code 裡的，其實是兩個東西？這種隱形的語言斷裂，正在每天偷走你團隊的時間。」
🎙️ 自問自答：「統一語言跟『建一份詞彙表』差在哪？」——詞彙表是靜態的死文件；統一語言是活的，它長在每天的對話、白板、程式碼裡，而且會隨理解加深不斷演化。
🎙️ 帶走的一題：「挑一個你 code 裡的類別名或方法名，唸出來給業務方聽——他聽得懂嗎？如果聽不懂，那很可能就是模型還沒對齊領域的訊號。」
更大範圍關聯
- DDD 的第一支柱：統一語言和限界上下文（第 10 集）是 Evans 戰略思想的兩根頂梁柱。記住一句口訣：統一語言負責「在邊界內講同一種話」，限界上下文負責「劃出這種話成立的邊界」。
- 連到 BDD / 規格即文件：用業務語言寫可執行測試的思路，後來在 Cucumber、SpecFlow、Gherkin 這套 BDD 工具鏈裡發揚光大。可以說 BDD 是統一語言在測試端的具體實踐。
- 連到《重構》的命名：Fowler《Refactoring》和 Uncle Bob《Clean Code》都強調「揭示意圖的命名」。DDD 把這件事往上推一層：命名不只是讓 code 好讀，更是讓 code 講出領域的語言。命名困難往往是「領域還沒想清楚」的徵兆。
- 思想脈絡：「程式碼是溝通工具」這條線，從 SICP「程式要寫得讓人讀」到 Clean Code，DDD 接著說——而且要用「領域的語言」來讀。
錄製建議
- 建議時長：約 20-22 分鐘。配比：語言分裂的代價約 5 分、統一語言核心約 8 分、Cargo Router 兩段對話＋大聲建模約 7 分（這段最好現場「演」兩種說法的對比，效果最強）。
- 討論策略：這集很適合用「演對話」的方式錄——你親自把情境一那段冗長技術描述唸一遍，再唸情境二的精簡版，讓聽眾用耳朵感受差別，這比解釋一百句都有效。中段把「語言改變=模型改變」這條當主軸反覆敲。
- 提醒聽眾：這集是整季的地基，後面講 Bounded Context、講戰略設計，全都建立在「統一語言」這個概念上。把它聽紮實。