domain-modeling

1# 领域建模
2 
3在设计过程中主动构建并打磨项目的 domain model。这是 *active* discipline：挑战术语、发明 edge-case scenarios，并在概念成形的当下写入 glossary 和 decisions。
4 
5## 文件结构
6 
7多数 repos 只有一个 context：
8 
9```text
10/
11|- GLOSSARY.md
12|- docs/
13|  `- adr/
14|     |- 0001-event-sourced-orders.md
15|     `- 0002-postgres-for-write-model.md
16`- src/
17```
18 
19如果 root 有 `GLOSSARY-MAP.md`，说明 repo 有多个 contexts。map 指向每个 context 的位置：
20 
21```text
22/
23|- GLOSSARY-MAP.md
24|- docs/
25|  `- adr/                          -> system-wide decisions
26`- src/
27   |- ordering/
28   |  |- GLOSSARY.md
29   |  `- docs/adr/                  -> context-specific decisions
30   `- billing/
31      |- GLOSSARY.md
32      `- docs/adr/
33```
34 
35按需懒创建文件：只有在有内容要写时才创建。如果没有 `GLOSSARY.md`，当第一个 term 被解决时创建它。如果没有 `docs/adr/`，当第一个 ADR 需要出现时创建它。
36 
37## Session 期间
38 
39### 对照术语表质询
40 
41当用户使用的术语与 `GLOSSARY.md` 中既有语言冲突时，立即指出。"Your glossary defines 'cancellation' as X, but you seem to mean Y - which is it?"
42 
43### 打磨模糊用语
44 
45当用户使用模糊或过载术语时，提出一个精确的 canonical term。"You're saying 'account' - do you mean the Customer or the User? Those are different things."
46 
47### 讨论具体场景
48 
49讨论 domain relationships 时，用具体场景做压力测试。发明能探测 edge cases 的场景，迫使用户精确定义概念之间的 boundaries。
50 
51### 与代码交叉对照
52 
53当用户描述某事如何工作时，检查代码是否同意。如果发现矛盾，要指出："Your code cancels entire Orders, but you just said partial cancellation is possible - which is right?"
54 
55### 就地更新 GLOSSARY.md
56 
57当一个 term 被解决时，立刻更新 `GLOSSARY.md`。不要批量攒到最后；随着概念出现就捕获。使用 [GLOSSARY-FORMAT.md](./GLOSSARY-FORMAT.md) 中的格式。
58…