用途
Domain Modeling 是一个在项目设计与开发过程中主动构建和打磨领域模型的技能。它的定位是“主动的纪律”：挑战术语、发明边界场景，并在术语和决策成型的当下就写入词汇表和决策记录。
该技能明确区分了“改变模型”与“仅仅消费模型”。仅仅阅读 GLOSSARY.md 来获取词汇不属于此技能——那只是任何技能都能做到的一行习惯。此技能适用于你正在改变模型，而不仅仅是消费模型的场景。
主要能力
- 对照词汇表挑战：当用户使用的术语与 GLOSSARY.md 中已有语言冲突时，立即指出。例如：“你的词汇表把 'cancellation' 定义为 X，但你似乎指的是 Y。到底是哪一个？”
- 锐化模糊语言：当用户使用含糊或过载的术语时，提出精确的规范术语。例如：“你说的是 'account'：你指的是 Customer 还是 User？这是两个不同的东西。”
- 讨论具体场景：在讨论领域关系时，用具体场景进行压力测试。发明探测边界情况的场景，迫使用户精确界定概念之间的边界。
- 与代码交叉引用：当用户陈述某事物如何工作时，检查代码是否一致。如果发现矛盾，就提出来：“你的代码取消整个 Orders，但你刚才说部分取消是可能的。哪个是对的？”
- 内联更新 GLOSSARY.md：当术语确定时，立即更新 GLOSSARY.md。不要批量处理，要在发生时即时捕获。使用 GLOSSARY-FORMAT.md 中的格式。
- 谨慎提供 ADR：仅在同时满足三个条件时才建议创建 ADR（见下文）。
使用方式
文件结构
大多数仓库只有一个上下文：
/
├── GLOSSARY.md
├── docs/
│ └── adr/
│ ├── 0001-event-sourced-orders.md
│ └── 0002-postgres-for-write-model.md
└── src/
如果根目录存在 GLOSSARY-MAP.md，则仓库有多个上下文。该映射指向每个上下文所在的位置：
/
├── GLOSSARY-MAP.md
├── docs/
│ └── adr/ ← 系统级决策
├── src/
│ ├── ordering/
│ │ ├── GLOSSARY.md
│ │ └── docs/adr/ ← 上下文特定决策
│ └── billing/
│ ├── GLOSSARY.md
│ └── docs/adr/
文件按需惰性创建：只有当你确实有内容要写时才创建。如果不存在 GLOSSARY.md，在第一个术语确定时创建它。如果不存在 docs/adr/，在需要第一个 ADR 时创建它。
GLOSSARY.md 的约束
GLOSSARY.md 应完全不含实现细节。不要将 GLOSSARY.md 当作规范、草稿本或实现决策的存放处。它只是一个词汇表，仅此而已。
ADR 的创建条件
仅在以下三个条件全部为真时才建议创建 ADR：
- 难以逆转：以后改变主意的成本是有意义的。
- 缺乏上下文会令人惊讶：未来的读者会疑惑“他们为什么这样做？”
- 是真实权衡的结果：存在真正的替代方案，而你出于特定原因选择了一个。
如果三个条件中缺少任何一个，就跳过 ADR。使用 ADR-FORMAT.md 中的格式。
适用场景
- 讨论代码库术语时
- 编写或编辑 GLOSSARY.md 时
- 记录或编辑 ADR 时
- 需要改变而非仅仅消费领域模型时
限制
- 仅阅读 GLOSSARY.md 获取词汇不属于此技能范围。
- GLOSSARY.md 不得包含实现细节。
- ADR 必须满足全部三个条件才建议创建。
- 关于具体的安装命令、收费方式、支持平台等信息，资料中暂未提供。