領域建模（Domain Modeling）

Was macht 領域建模（Domain Modeling）?

全程使用繁體中文與使用者溝通。GLOSSARY.md 與 ADR 以繁體中文撰寫；術語本身可以中英並列（例如「替代料（Alternate Part）」），因為程式碼裡的命名通常是英文。

在設計的過程中，主動建立並磨利專案的領域模型。這是一門主動的紀律：挑戰用詞、發明邊界情境，並在術語與決策一成形時就立刻寫下來。（只是讀取 GLOSSARY.md 來對齊用詞不算這個 skill，那是任何 skill 都該有的小習慣。這個 skill 用在你正在改變模型，而不只是使用它的時候。）

檔案結構

大多數 repo 只有一個 context：

/
├── GLOSSARY.md
├── docs/
│   └── adr/
│       ├── 0001-cost-rollup-uses-moq-price-break.md
│       └── 0002-sqlite-for-part-cache.md
└── src/

如果 repo 根目錄有 GLOSSARY-MAP.md，代表這個 repo 有多個 context，由這張地圖指出每個 context 的位置：

/
├── GLOSSARY-MAP.md
├── docs/
│   └── adr/                          ← 全系統層級的決策
├── src/
│   ├── sourcing/
│   │   ├── GLOSSARY.md
│   │   └── docs/adr/                 ← 該 context 專屬的決策
│   └── costing/
│       ├── GLOSSARY.md
│       └── docs/adr/

檔案採延遲建立：有東西要寫時才建立。如果還沒有 GLOSSARY.md，在第一個術語被確定時建立；如果還沒有 docs/adr/，在需要第一份 ADR 時建立。

進行中要做的事

對照術語表提出質疑

當使用者用的詞和 GLOSSARY.md 既有的定義衝突時，立刻指出。例如：「術語表把『替代料』定義為 X，但你現在的意思似乎是 Y。是哪一個？」

磨利模糊的用語

當使用者用了含糊或一詞多義的字眼，提出一個精確的標準用詞。例如：「你說的『料號』是指我們內部料號，還是原廠料號（MPN）？這兩者是不同的東西。」

用具體情境檢驗

討論領域概念之間的關係時，用具體情境做壓力測試。發明會探到邊界的情境，逼使用者把概念之間的界線講精確。例如：「如果原廠料號一樣但封裝不同，算同一顆料還是替代料？」

與程式碼交叉比對

當使用者描述某件事如何運作時，檢查程式碼是否一致。發現矛盾就提出來：「你的程式在計算成本時只看第一個價格級距，但你剛才說要依 MOQ 取對應級距。哪個才對？」

當場更新 GLOSSARY.md

術語一確定，就當場更新 GLOSSARY.md。不要累積起來一次寫，要隨發生隨記錄。格式見 GLOSSARY-FORMAT.md。

GLOSSARY.md 裡不能有任何實作細節。不要把它當成 spec、草稿本或存放實作決策的地方。它就是術語表，僅此而已。

謹慎提議 ADR

只有在以下三點同時成立時，才提議建立 ADR：

1. 難以反悔：之後改變主意的成本很高
2. 沒有背景就會覺得奇怪：未來的讀者會想「為什麼要這樣做？」
3. 真實取捨的結果：當時確實有其他可行方案，而你基於特定理由選了其中一個

三點缺任何一點就跳過。格式見 ADR-FORMAT.md。