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 中的格式。