Domain Modeling

領域模型

在設計過程中主動建立並磨利專案的領域模型。這是主動的紀律——挑戰術語、發明邊緣案例情境，並在術語定案的那一刻把詞彙表和決策寫下來。（光是讀 CONTEXT.md 來取得詞彙不是本技能——那是一行程式碼習慣，任何技能都能做。本技能是用於當你在改變模型，而不只是消費它。）

檔案結構

多數 repo 只有單一上下文：

/
├── CONTEXT.md
├── docs/
│   └── adr/
│       ├── 0001-event-sourced-orders.md
│       └── 0002-postgres-for-write-model.md
└── src/

如果根目錄有 CONTEXT-MAP.md，表示 repo 有多個上下文。地圖指向每個上下文所在位置：

/
├── CONTEXT-MAP.md
├── docs/
│   └── adr/                          ← system-wide decisions
├── src/
│   ├── ordering/
│   │   ├── CONTEXT.md
│   │   └── docs/adr/                 ← context-specific decisions
│   └── billing/
│       ├── CONTEXT.md
│       └── docs/adr/

惰性地建立檔案——只在有東西要寫時才建。如果沒有 CONTEXT.md，第一個術語定案時建立一個。如果沒有 docs/adr/，需要第一個 ADR 時建立。

會話期間

對照詞彙表挑戰

當使用者使用的術語與 CONTEXT.md 中既有的語言衝突時，立刻點出來。「你的詞彙表把 'cancellation' 定義為 X，但你似乎指的是 Y——哪個才對？」

磨利模糊的語言

當使用者使用含糊或過載的術語時，提出精確的規範術語。「你說 'account'——你指的是 Customer 還是 User？那是不同的東西。」

討論具體情境

當領域關係正在被討論時，用具體情境壓力測試它們。發明探索邊緣案例、迫使使用者對概念之間的邊界精確起來的情境。

與程式碼交叉比對

當使用者陳述某個東西如何運作時，檢查程式碼是否同意。如果發現矛盾，把它浮上檯面：「你的程式碼取消整個 Order，但你剛才說可以部分取消——哪個才對？」

內嵌更新 CONTEXT.md

當一個術語定案時，就地更新 CONTEXT.md。不要累積再一次處理——邊發生邊捕捉。使用 CONTEXT-FORMAT.md 中的格式。

CONTEXT.md 應該完全不含實作細節。不要把 CONTEXT.md 當成規格、便條紙，或實作決策的倉庫。它是詞彙表，而且僅此而已。

斟酌提供 ADR

只有三個條件都成立時，才主動提出建立 ADR：

1. 難以逆轉——之後改變心意的成本是實際的
2. 沒有上下文會令人驚訝——未來的讀者會想「為什麼他們要這樣做？」
3. 真實取捨的結果——存在真正的替代方案，你基於特定理由選了其中一個

如果三個條件缺一，就跳過 ADR。使用 ADR-FORMAT.md 中的格式。