domain-modeling

领域建模

在设计过程中主动构建并打磨项目的领域模型。这是主动的工作方式：质疑术语、构造边界情形的场景，并在概念成形的当下把术语表和决策记录下来。（仅仅阅读 GLOSSARY.md 来查询词汇不属于此技能，那只是任何技能都能做到的一个简单习惯。本技能针对的是修改模型的时候，而不只是使用模型的时候。）

文件结构

大多数仓库只有一个上下文：

/
├── GLOSSARY.md
├── docs/
│   └── adr/
│       ├── 0001-event-sourced-orders.md
│       └── 0002-postgres-for-write-model.md
└── src/

如果仓库根目录存在 GLOSSARY-MAP.md，则说明该仓库有多个上下文。该映射文件指明每个上下文的位置：

/
├── GLOSSARY-MAP.md
├── docs/
│   └── adr/                          ← system-wide decisions
├── src/
│   ├── ordering/
│   │   ├── GLOSSARY.md
│   │   └── docs/adr/                 ← context-specific decisions
│   └── billing/
│       ├── GLOSSARY.md
│       └── docs/adr/

文件按需惰性创建：只有在有内容需要写入时才创建。如果不存在 GLOSSARY.md，则在确定第一个术语时创建它。如果不存在 docs/adr/，则在需要第一份 ADR 时创建它。

会话过程中

对照术语表进行质疑

当用户使用的术语与 GLOSSARY.md 中已有的用语相冲突时，立即指出。例如："你的术语表将“取消”定义为 X，但你似乎指的是 Y。到底是哪一个？"

澄清模糊的表述

当用户使用含糊或含义过载的术语时，提出一个精确的标准术语。例如："你说的“账户”，是指客户（Customer）还是用户（User）？这两者是不同的东西。"

结合具体场景讨论

当讨论领域概念之间的关系时，用具体场景对其进行压力测试。构造能够探查边界情形的场景，迫使用户明确各概念之间的边界。

与代码交叉核对

当用户说明某件事的运作方式时，检查代码是否与之吻合。如果发现矛盾，把它指出来。例如："你的代码会取消整个订单（Order），但你刚才说可以部分取消。到底哪个是对的？"

就地更新 GLOSSARY.md

术语一经确定，就在当场更新 GLOSSARY.md。不要攒到之后批量处理：应在发生时就记录下来。使用 GLOSSARY-FORMAT.md 中的格式。

GLOSSARY.md 应完全不包含实现细节。不要把 GLOSSARY.md 当作规格说明、草稿本或实现决策的存放处。它就是一份术语表，别无其他用途。

谨慎提议 ADR

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

1. 难以逆转：日后改变主意的代价较大
2. 脱离上下文会令人困惑：未来的读者会疑惑“他们为什么要这样做？”
3. 是真实权衡的结果：存在真正的替代方案，而你基于具体理由选择了其中一种

如果三个条件中缺少任何一个，则跳过 ADR。使用 ADR-FORMAT.md 中的格式。