domain-modeling

name	domain-modeling
description	构建并持续校准项目的领域模型。适用于需要明确领域术语或统一语言、记录架构决策，或其它 skill 需要维护领域模型的场景。

领域建模

在设计过程中主动构建并校准项目的领域模型：质疑术语、构造边界场景，并在词汇和决策明确时立即记录下来。仅仅读取 CONTEXT.md 以沿用词汇不属于此 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，需要记录第一条 ADR 时才创建 docs/adr/。

会话期间

对照词汇表检查

用户使用的术语与 CONTEXT.md 冲突时，立即指出。例如：“词汇表将‘取消’定义为 X，但你现在似乎是指 Y——以哪个为准？”

收紧模糊语言

用户使用含糊或含义过载的词时，提出精确的规范术语。例如：“这里的‘账号’是指 Customer 还是 User？它们是两个不同概念。”

讨论具体场景

讨论领域关系时，用具体场景进行压力测试。主动构造边界案例，迫使概念之间的边界变得精确。

与代码交叉验证

用户描述系统行为时，检查代码是否一致。发现矛盾便直接指出，例如：“代码会取消整个 Order，但你刚才说可以部分取消——以哪个为准？”

即时更新 CONTEXT.md

术语一旦确认，立即更新 CONTEXT.md，不要集中到最后处理。格式遵循 CONTEXT-FORMAT.md。

CONTEXT.md 只能包含词汇定义，不能包含实现细节；不要把它当作规格、草稿或实现决策仓库。

谨慎提出 ADR

只有同时满足以下三个条件时，才建议创建 ADR：

1. 难以逆转：日后改变决定的成本显著。
2. 缺少背景便难以理解：未来读者会疑惑为什么这样设计。
3. 源于真实取舍：确实比较过替代方案，并基于明确理由做出选择。

缺少任一条件就跳过 ADR。格式遵循 ADR-FORMAT.md。