domain-modeling

领域建模

在设计过程中，积极构建并完善项目的领域模型。这是一项主动实践：质疑术语、构思边界情况，并在概念明确时立即记录术语表和决策。（仅仅阅读 CONTEXT.md 了解词汇并不属于这项技能：这是任何技能都能做到的一行习惯。这项技能适用于你正在更改模型，而不只是使用它的情况。）

文件结构

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

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

如果根目录中存在 CONTEXT-MAP.md，则说明代码仓库有多个上下文。该映射会指出各个上下文所在的位置：

/
├── CONTEXT-MAP.md
├── docs/
│   └── adr/                          ← system-wide decisions
├── src/
│   ├── ordering/
│   │   ├── CONTEXT.md
│   │   └── docs/adr/                 ← context-specific decisions
│   └── billing/
│       ├── CONTEXT.md
│       └── docs/adr/

按需创建文件：只有在有内容需要记录时才创建。如果不存在 CONTEXT.md，则在第一个术语得到明确时创建。如果不存在 docs/adr/，则在需要记录第一个 ADR 时创建。

会话期间

对照术语表提出质疑

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

明确模糊的语言

当用户使用含糊或含义过多的术语时，建议一个精确的规范术语。“你说的是‘账户’：指的是 Customer 还是 User？它们是不同的概念。”

讨论具体场景

讨论领域关系时，用具体场景检验它们。构思一些探查边界情况、促使用户明确概念边界的场景。

对照代码进行核查

当用户陈述某项功能的工作方式时，检查代码是否一致。如果发现矛盾，就指出来：“你的代码会取消整个 Order，但你刚才说可以部分取消。哪种说法才对？”

在对话中更新 CONTEXT.md

术语一旦明确，就立即在 CONTEXT.md 中更新。不要把这些更新攒到一起：明确一个就记录一个。使用 CONTEXT-FORMAT.md 中的格式。

CONTEXT.md 中不应包含任何实现细节。不要把 CONTEXT.md 当作规范、草稿本或实现决策的存放处。它只是术语表，仅此而已。

谨慎提出 ADR

只有同时满足以下三项条件时，才提出创建 ADR：

1. 难以逆转：以后改变决定的成本很高
2. 没有上下文就令人意外：未来的读者会疑惑“为什么要这样做？”
3. 源于真正的权衡：确实存在其他方案，且你基于具体原因选择了其中一个

只要有一项不满足，就不要创建 ADR。使用 ADR-FORMAT.md 中的格式。