domain-modeling

领域建模

在设计过程中主动构建和打磨项目的领域模型。这是一项主动的纪律：挑战术语、构造边界场景、在术语和决策刚成形的时刻就把它们写下来。（仅仅是读 CONTEXT.md 找术语不算这个 skill：那只是任何 skill 都能顺手做的一件小事。这个 skill 用在你正在改变模型、而不只是使用模型的时候。）

文件结构

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

/
├── 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。到底是哪个？”用户确认要改术语时，先更新 CONTEXT.md 再继续。未确认前以文件中的定义为准。

锐化模糊语言

当用户使用模糊或含义重叠的词时，提出一个精确的标准术语。比如用户说“账户”时，问：指的是 Customer 还是 User？这是两个不同的概念。

讨论具体场景

当讨论领域关系时，用具体场景压测它们。构造场景探查边界情况，迫使用户把概念之间的边界说精确。

与代码交叉验证

当用户陈述某事怎么运作时，检查代码是否与之相符。发现矛盾就摆出来：“你的代码取消的是整个 Order，但你刚说支持部分取消。哪个对？”

当场更新 CONTEXT.md

术语确定时，当场更新 CONTEXT.md。不要攒着：发生就记。用 CONTEXT-FORMAT.md 中的格式。

CONTEXT.md 应当完全不包含实现细节。不要把 CONTEXT.md 当成任务要求、草稿本或实现决策的仓库。它就是术语表，不是别的。

克制地提议 ADR

只在以下三条同时为真时才提议创建 ADR：

1. 难以撤销：事后改变主意的成本很大
2. 缺乏上下文会令人困惑：未来的读者会想“他们为什么这么做？”
3. 源于真正的权衡：存在真实的替代方案，你因特定理由选了其中一个

三条缺一条，就跳过 ADR。用 ADR-FORMAT.md 中的格式。