領域驅動設計 DDD
Eric Evans｜用領域模型馴服業務複雜度
⚡ 即用工具 三張可直接上手的卡
🎯 什麼情境該想到我
當工程師與業務/PM「講的是同一件事卻用不同詞」、需求翻成程式碼常失真時。
⚙️ 怎麼用
- 建立一套團隊 + 領域專家共用的詞彙：一個概念一個名字，全員（含文件、對話、程式碼）都用它。
- 讓程式碼直接反映這套語言：類別/方法名 = 領域術語，讀 code 像讀業務。
- 發現詞彙模糊或衝突，就當場澄清並更新——語言的演進就是模型的演進。
- 詞彙若在不同脈絡意義不同 → 那是要切 工具-限界上下文 的訊號。
🧪 我實際套用的紀錄
- 2026-07-14：（待填）
⚠️ 注意
- 通用語言要「活」在日常溝通與程式碼裡，不是一份放著長灰塵的詞彙表。
🔗 相關工具
🎯 什麼情境該想到我
當系統/模型越長越大越糊，或發現「同一個名詞在不同部門意義不同」時。
⚙️ 怎麼用
- 劃出邊界：在某個邊界內，一套模型與 工具-通用語言 保持一致、無歧義。
- 一個詞在不同上下文意義不同 → 就該分成不同上下文（例：「商品」在銷售 vs 物流意義不同）。
- 用 Context Map 描述上下文之間的關係（上下游、防腐層 ACL、共享核心…）。
- 邊界也是團隊、部署（含微服務拆分）的自然切點。
🧪 我實際套用的紀錄
- 2026-07-14：（待填）
⚠️ 注意
- 別追求「一個統一大模型」——那通常是複雜度失控的來源。邊界內一致即可。
🔗 相關工具
- 工具-通用語言 —— 一體兩面，語言只在上下文內統一，邊界就是語意換軌的地方
- 工具-實體值物件與聚合 —— 往內一層，上下文之內再決定實體與聚合怎麼切
- 工具-管理複雜度 —— 為什麼要畫邊界，切開之後每次只需要理解一個上下文
🎯 什麼情境該想到我
當你在設計領域模型的結構，猶豫「這東西該有身分嗎、一致性邊界該畫在哪」時。
⚙️ 怎麼用（三個建構區塊）
- Entity（實體）：有唯一身分、生命週期中即使屬性變了仍是「同一個」（如：一個訂單）。
- Value Object（值物件）：沒有身分，只看值是否相等、不可變（如：金額、地址）。優先用值物件，簡單又安全。
- 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]]