domain-modelinglisted

# Domain Modeling — 领域建模 主动构建和打磨项目的领域模型。这是*主动*纪律——质疑术语，发明边界场景，词汇和决定一旦结晶就写下来。 ## 文件结构 单一上下文的仓库： ``` ├── CONTEXT.md # 领域词汇表 ├── docs/adr/ │ ├── 0001-events.md │ └── 0002-postgres.md └── src/ ``` 多上下文仓库（有 `CONTEXT-MAP.md` 时）： ``` ├── CONTEXT-MAP.md # 指向各上下文 ├── docs/adr/ # 系统级决策 ├── src/ordering/ │ ├── CONTEXT.md # 上下文特定词汇 │ └── docs/adr/ # 上下文特定决策 └── src/billing/ ├── CONTEXT.md └── docs/adr/ ``` 懒创建文件——只有在有内容可写时才创建。 ## 会话中的操作 ### 对照词汇表质疑 当用户使用与 `CONTEXT.md` 现有语言冲突的术语时，立即指出。"你的词汇表把 'cancellation' 定义为 X，但你似乎在说 Y——到底是哪个？" ### 打磨模糊语言 当用户使用模糊或过载的术语时，提出精确的规范术语。"你在说 'account'——你指的是 Customer 还是 User？这是两个不同的东西。" ### 讨论具体场景 当领域关系在讨论中时，用具体场景压力测试。发明探测边界情况的场景，迫使用户在概念边界上精确。 ### 对照代码交叉验证 当用户说明某件事如何工作时，检查代码是否同意。如果发现矛盾，揭示它："你的代码取消了整个 Orders，但你刚才说部分取消是可能的——哪个是对的？" ### 行内更新 CONTEXT.md 当术语被解析时，立即更新 `CONTEXT.md`。不要批量做——发生时就捕获。 `CONTEXT.md` 应该完全不含实现细节。不要把它当 spec、草稿或实现决定的仓库。它是词汇表，没有别的。 ### 慎用 ADR 只在三者都满足时才创建 ADR： 1. **难逆转** — 以后改变主意的成本很大 2. **无上下文会令人惊讶** — 未来读者会好奇"为什么这样做？" 3. **真正权衡的结果** — 有真正的替代方案，你选了某个有特定理由的