domain-modeling

name	domain-modeling
description	构建并打磨项目的领域模型。当用户想要确定领域术语或通用语言、记录一项架构决策，或当其他技能需要维护领域模型时使用。

领域建模

在设计过程中主动构建并磨锐项目的领域模型。这是一门主动的纪律——挑战术语、构造边缘场景，并在术语表和决策成形的那一刻就把它们写下来。（仅仅阅读 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/                          ← 系统级决策
├── src/
│   ├── ordering/
│   │   ├── CONTEXT.md
│   │   └── docs/adr/                 ← 上下文专属决策
│   └── billing/
│       ├── CONTEXT.md
│       └── docs/adr/

惰性创建文件——只在你有东西要写时才创建。如果不存在 CONTEXT.md，在第一个术语被确定下来时创建一个。如果不存在 docs/adr/，在第一个 ADR 需要时创建它。

会话期间

对照术语表进行挑战

当用户使用的术语与 CONTEXT.md 中现有的语言冲突时，立即指出来。「你的术语表把『cancellation』定义为 X，但你似乎指的是 Y——到底是哪个？」

磨锐模糊的语言

当用户使用含糊或多义的术语时，提出一个精确的规范术语。「你说的是『account』——你指的是 Customer 还是 User？那是两个不同的东西。」

讨论具体场景

当在讨论领域关系时，用具体场景对它们进行压力测试。构造能探测边缘情况的场景，迫使用户对各概念之间的边界表述得精确。

与代码交叉引用

当用户陈述某个东西是如何工作的时候，检查代码是否与之一致。如果你发现矛盾，就把它摆出来：「你的代码取消的是整个 Order，但你刚说部分取消是可能的——哪个才对？」

就地更新 CONTEXT.md

当一个术语被确定下来时，当场更新 CONTEXT.md。不要把它们攒起来——在它们发生的当下就捕获下来。使用 CONTEXT-FORMAT.md 中的格式。

CONTEXT.md 应完全不含实现细节。不要把 CONTEXT.md 当作规格说明、草稿纸或实现决策的仓库。它是一个术语表，仅此而已。

谨慎地提议 ADR

只有在以下三点全部成立时，才提议创建 ADR：

1. 难以逆转——日后改变主意的代价是实质性的
2. 没有上下文就令人费解——未来的读者会想「他们为什么要这样做？」
3. 是真实权衡的结果——存在真正的备选方案，而你出于具体理由选了其中一个

如果三者中缺了任何一个，就跳过 ADR。使用 ADR-FORMAT.md 中的格式。