领域建模

术语漂移是模型腐化的开始

一个团队里，cancellation 被两个人用成两个意思；产品经理说「account」，工程师以为是 Customer，实际落库的是 User。这类分歧在评审会上不会立刻爆发，而是顺着需求、代码和工单慢慢沉淀成返工成本。等到某次重构才发现，Cancellation 在代码里只支持整单取消，而业务早已默认支持单行部分取消——争论的其实是两份不同的模型。

领域建模技能要处理的就是这个阶段：当你正在改变模型，而不是单纯查一个词的定义时。

它具体怎么做

技能把你当作领域建模师，介入设计讨论并主动做四件事：

• 对照术语表挑战冲突：你的说法与 CONTEXT.md 不一致时当场指出，要求明确指的是哪个概念，而不是默认对方与文档一致。
• 打磨模糊或过载词：对含糊词汇提议更精确的规范词。比如「account」需要被拆成 Customer 还是 User，因为两者不是同一个东西。
• 用具体场景压力测试关系：拿边界场景逼出概念边界，避免只在抽象层面达成一致。
• 对照代码验证说法：你描述机制如何工作时，它会去读实现，矛盾时直接摆出「代码取消整单，但你刚说支持部分取消——哪个对」。

落盘方式有两种，且都是惰性创建，有内容才建文件：术语敲定当场内联更新 CONTEXT.md，格式见 references/template.md，且内容只保留领域词，完全不含实现细节；ADR 只在三个条件同时满足时才提议，即决策难逆转、脱离上下文后后人会困惑、确实存在真实取舍。文件结构上，单一上下文是根目录的 CONTEXT.md 加 docs/adr/，多上下文则由 CONTEXT-MAP.md 编排。

产出被整理为 DomainModelDelta 工件，包含术语变更与 ADR，供 codebase-design、triage、to-spec 等下游流程当作词汇基础。

适用边界

这个技能不负责把 CONTEXT.md 当规格、草稿或实现决策仓库。它只是术语表，模块名除非本身带有领域含义，否则不应写进去。如果只是想查一下某个词以前怎么定义的，任何技能都能做到，不需要这套流程。真正需要它的时刻，是你准备改动模型、并且这个改动会让后续沟通建立在新的词汇之上。