领域建模
在设计的过程中主动构建并打磨项目的领域模型。这是一项主动的实践：质疑术语、构想边界场景，并在术语与决策一旦成形的当下就把词汇表和决策写下来。（仅仅为了查词而阅读 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/ ← system-wide decisions ├── src/ │ ├── ordering/ │ │ ├── GLOSSARY.md │ │ └── docs/adr/ ← context-specific decisions │ └── billing/ │ ├── GLOSSARY.md │ └── docs/adr/
按需创建文件：只在确实有东西要写的时候才建。如果还没有 GLOSSARY.md，就在第一个术语定下来时创建一个。如果还没有 docs/adr/，就在需要第一条 ADR 时创建它。
会话期间
对照词汇表提出质疑
当用户使用的术语与 GLOSSARY.md 里既有的说法冲突时，立刻指出来。「你的词汇表把“cancellation”定义为 X，但你似乎想说的是 Y。到底是哪一个？」
打磨含糊的说法
当用户使用含糊或一词多义的词时，提出一个精确的规范术语。「你在说“account”：你指的是 Customer 还是 User？这是两回事。」
讨论具体场景
当讨论到领域关系时，用具体的场景给它们做压力测试。构想一些触及边界情况的场景，逼用户把概念之间的界线说清楚。
与代码交叉核对
当用户说明某件事是怎么运作的，去核对代码是否与之相符。如果你发现矛盾，就把它摆出来：「你的代码会取消整张 Order，但你刚说部分取消是可能的。哪个才是对的？」
就地更新 GLOSSARY.md
当一个术语定下来时，就当场更新 GLOSSARY.md。不要攒着一起改：事情发生的时候就记下来。使用 GLOSSARY-FORMAT.md 里的格式。
GLOSSARY.md 里应当完全没有实现细节。不要把 GLOSSARY.md 当成规格说明、草稿纸，或实现决策的存放处。它是词汇表，仅此而已。
谨慎地提议写 ADR
只有当以下三条同时成立时，才提议创建 ADR：
- 难以逆转：日后改变主意的代价不小
- 没有上下文会让人意外：未来的读者会琢磨「他们当初为什么这么做？」
- 真正权衡后的结果：当时确实有别的选择，而你出于具体理由选了其中一个
三条里缺任何一条，就跳过 ADR。使用 ADR-FORMAT.md 里的格式。
