domain-modeling

name	domain-modeling
description	构建并打磨项目的领域模型。适用于用户希望确定领域术语或统一语言、记录架构决策，或其他 Skill 需要维护领域模型时。

领域建模

在设计过程中主动构建并打磨项目的领域模型。这是一套主动纪律：质疑术语、构造边缘场景，并在术语和决策刚刚明确时立即写入文档。（只是为了查阅词汇而读取 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/                          ← 系统级决策
├── 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。