domain-modeling

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

领域建模（Domain Modeling）

在设计过程中主动构建并打磨项目的领域模型。这是一门 主动 的功夫——挑战术语、构造边界情形的场景，并在术语与决策刚刚清晰下来的那一刻就把它们写下来。（仅仅 阅读 CONTEXT.md 获取词汇并不属于这个技能——那是任何技能都能顺手做的一件小事。这个技能面向的是你正在 修改 模型的场景，而不只是消费它。）

文件结构

大多数仓库只有单一上下文（context）：

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