xufang5219/领域建模

领域建模 是做什么的？

在设计中主动构建和打磨项目的领域模型。这是一项 主动 的修炼：挑战术语、创造边界案例、在概念固化时立即记录词汇表和决策。（仅阅读 GLOSSARY.md 获取词汇并不属于本技能：那是任何技能都能做到的一行习惯。本技能适用于当你在改变模型，而不仅仅是消费它时。）

文件结构

大多数仓库只有一个上下文：

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

如果根目录存在 GLOSSARY-MAP.md，则仓库有多个上下文。该映射指向每个上下文所在的位置：

/
├── GLOSSARY-MAP.md
├── docs/
│   └── adr/                          ← 系统级决策
├── src/
│   ├── ordering/
│   │   ├── GLOSSARY.md
│   │   └── docs/adr/                 ← 上下文特定决策
│   └── billing/
│       ├── GLOSSARY.md
│       └── docs/adr/

惰性创建文件：仅当有内容需要记录时才创建。如果不存在 GLOSSARY.md，则在首个术语确定时创建它。如果不存在 docs/adr/，则在首个 ADR 需要时创建它。

会话期间

挑战词汇表

当用户使用的术语与 GLOSSARY.md 中已有的语言冲突时，立即指出。“你的词汇表将‘取消’定义为 X，但你似乎指的是 Y。究竟是哪一个？”

打磨模糊语言

当用户使用模糊或过于宽泛的术语时，提出一个精确的规范术语。“你说的是‘账户’：你指的是客户还是用户？这是不同的东西。”

讨论具体场景

当讨论领域关系时，使用具体场景进行压力测试。创造那些能探测边界案例的场景，迫使用户精确地界定概念之间的界限。

与代码交叉引用

当用户陈述某个行为如何运作时，检查代码是否一致。如果发现矛盾，抛出它：“你的代码取消了整个订单，但你刚才说可以部分取消。哪个正确？”

即时更新 GLOSSARY.md

当术语确定后，立即更新 GLOSSARY.md。不要批量处理：随时捕获，随时记录。使用 GLOSSARY-FORMAT.md 中的格式。

GLOSSARY.md 应完全不含实现细节。不要将 GLOSSARY.md 视为规范、草稿或实现决策的仓库。它只是一个词汇表，仅此而已。

谨慎提供 ADR

仅在以下三个条件同时满足时才提议创建 ADR：

1. 难以撤销：以后改变主意的成本很高
2. 缺少上下文会令人费解：未来的读者会疑惑“他们为什么这么做？”
3. 是真实权衡的结果：存在真正的备选方案，并且你基于特定理由选择了其中一个

如果缺少任何一条，跳过 ADR。使用 ADR-FORMAT.md 中的格式。