領域驅動設計 Domain-Driven Design

📌 30 秒摘要（Layer 3）

面對複雜業務，最大的敵人不是技術而是領域的複雜度。DDD 主張把重心放在「領域模型」：開發者與領域專家用同一套通用語言溝通，並讓程式碼直接反映這套語言。再用限界上下文切開大系統、用實體/值物件/聚合組織模型，讓模型在各自邊界內保持一致與清晰。

🗺 心智圖（Canvas）

領域驅動設計

領域驅動設計 DDD

Eric Evans｜用領域模型馴服業務複雜度

⚡ 即用工具 三張可直接上手的卡

工具-通用語言

🎯 什麼情境該想到我

當工程師與業務/PM「講的是同一件事卻用不同詞」、需求翻成程式碼常失真時。

⚙️ 怎麼用

1. 建立一套團隊 + 領域專家共用的詞彙：一個概念一個名字，全員（含文件、對話、程式碼）都用它。
2. 讓程式碼直接反映這套語言：類別/方法名 = 領域術語，讀 code 像讀業務。
3. 發現詞彙模糊或衝突，就當場澄清並更新——語言的演進就是模型的演進。
4. 詞彙若在不同脈絡意義不同 → 那是要切 工具-限界上下文 的訊號。

🧪 我實際套用的紀錄

• 2026-07-14：（待填）

⚠️ 注意

• 通用語言要「活」在日常溝通與程式碼裡，不是一份放著長灰塵的詞彙表。

🔗 相關工具

• 工具-限界上下文 —— 配套概念，通用語言只在一個上下文內成立，跨上下文同詞可以不同義
• 工具-有意義的命名 —— 落到程式碼那一步，通用語言的詞要原封不動出現在型別與方法名上

工具-限界上下文

🎯 什麼情境該想到我

當系統/模型越長越大越糊，或發現「同一個名詞在不同部門意義不同」時。

⚙️ 怎麼用

1. 劃出邊界：在某個邊界內，一套模型與 工具-通用語言 保持一致、無歧義。
2. 一個詞在不同上下文意義不同 → 就該分成不同上下文（例：「商品」在銷售 vs 物流意義不同）。
3. 用 Context Map 描述上下文之間的關係（上下游、防腐層 ACL、共享核心…）。
4. 邊界也是團隊、部署（含微服務拆分）的自然切點。

🧪 我實際套用的紀錄

• 2026-07-14：（待填）

⚠️ 注意

• 別追求「一個統一大模型」——那通常是複雜度失控的來源。邊界內一致即可。

🔗 相關工具

• 工具-通用語言 —— 一體兩面，語言只在上下文內統一，邊界就是語意換軌的地方
• 工具-實體值物件與聚合 —— 往內一層，上下文之內再決定實體與聚合怎麼切
• 工具-管理複雜度 —— 為什麼要畫邊界，切開之後每次只需要理解一個上下文

工具-實體值物件與聚合

🎯 什麼情境該想到我

當你在設計領域模型的結構，猶豫「這東西該有身分嗎、一致性邊界該畫在哪」時。

⚙️ 怎麼用（三個建構區塊）

1. Entity（實體）：有唯一身分、生命週期中即使屬性變了仍是「同一個」（如：一個訂單）。
2. Value Object（值物件）：沒有身分，只看值是否相等、不可變（如：金額、地址）。優先用值物件，簡單又安全。
3. Aggregate（聚合）：一組相關物件的一致性邊界，有一個 Aggregate Root 當唯一入口；外部只能透過 root 改動內部，交易一次只改一個聚合。

🧪 我實際套用的紀錄

• 2026-07-14：（待填）

⚠️ 注意

• 聚合別設太大（一致性成本高）；一次交易一個聚合，跨聚合用最終一致性（見 工具-Transactional-Outbox-Pattern）。

🔗 相關工具

• 工具-限界上下文 —— 上位邊界，聚合畫在上下文之內，先有上下文才知道聚合該多大
• 工具-通用語言 —— 命名來源，實體與值物件的名字要跟業務講的詞一致，否則模型會慢慢失真

🧱 建構元件 Building Blocks（9）

[[實體|實體 Entity]] ・ [[值物件（DDD）|值物件 Value Object]] [[聚合|聚合 Aggregate]] ・ [[儲存庫（DDD）|儲存庫 Repository]] [[工廠|工廠 Factory]] ・ [[領域服務|領域服務 Domain Service]] [[領域事件|領域事件 Domain Event]] ・ [[模組|模組 Module]] [[規格|規格 Specification]]

🗺 戰略設計 Strategic Design（6）

[[通用語言|通用語言 Ubiquitous Language]] [[限界上下文|限界上下文 Bounded Context]] [[上下文對應|上下文對應 Context Map]] [[核心子領域|核心子領域 Core Domain]] [[支撐子領域|支撐子領域 Supporting Subdomain]] [[通用子領域|通用子領域 Generic Subdomain]]

🔗 上下文對應模式 Context Map Patterns（9）

[[合作關係|合作關係 Partnership]] ・ [[共享核心|共享核心 Shared Kernel]] [[客戶-供應商|客戶-供應商 Customer-Supplier]] ・ [[追隨者|追隨者 Conformist]] [[防腐層|防腐層 Anticorruption Layer]] [[開放主機服務|開放主機服務 Open Host Service]] [[發布語言|發布語言 Published Language]] [[各行其道|各行其道 Separate Ways]] ・ [[大泥球|大泥球 Big Ball of Mud]]

Link to original

🧰 這本書給我的工具（即用快速工具）

• 工具-通用語言 — 跟業務方溝通、命名領域概念時
• 工具-限界上下文 — 大系統該怎麼切分時
• 工具-實體值物件與聚合 — 設計領域模型結構時

📖 完整型錄（詳解在 reference/）

🧱 建構元件 Building Blocks

• 實體 Entity、值物件 Value Object、聚合 Aggregate、儲存庫 Repository、工廠 Factory、領域服務 Domain Service、領域事件 Domain Event、模組 Module、規格 Specification

🗺 戰略設計 Strategic Design

• 通用語言 Ubiquitous Language、限界上下文 Bounded Context、上下文對應 Context Map、核心子領域 Core Domain、支撐子領域 Supporting Subdomain、通用子領域 Generic Subdomain

🔗 上下文對應模式 Context Map Patterns

• 合作關係 Partnership、共享核心 Shared Kernel、客戶-供應商 Customer-Supplier、追隨者 Conformist、防腐層 Anticorruption Layer、開放主機服務 Open Host Service、發布語言 Published Language、各行其道 Separate Ways、大泥球 Big Ball of Mud

✨ 關鍵重點（Layer 1–2）

• 模型驅動設計：程式碼與領域模型緊密對應，模型即設計。
• 通用語言（Ubiquitous Language）：團隊與專家共用同一套詞彙，貫穿討論與程式碼。
• 限界上下文（Bounded Context）：明確劃定某模型有效的邊界；跨界用 Context Map 對應。
• 建構區塊：Entity（有身分）、Value Object（無身分只看值）、Aggregate（一致性邊界）、Repository、Factory、Service。
• 精煉：區分核心領域與支撐子域，把心力投在核心。

💬 金句原文（Layer 0）

• 「模型與設計的核心互相塑造。」
• 「複雜性應對之道，在於一個好的領域模型。」

🔗 相關

• 與 工具-管理複雜度 同源（用邊界與模型馴服複雜度）
• 事件時序邊界可參 工具-Transactional-Outbox-Pattern