domain-modeling

领域建模

大多数构建错误都始于语言鸿沟：Agent 被丢进一个项目，却只能自己摸索术语，因此领域明明一个词就能说清，它却用了二十个词。共享语言可以弥合这道鸿沟。当代码、对话和模型都使用同一套词汇时，名称就能对应起来，导航成本会降低，模型推理时所需的 token 也会减少，因为它可以用更精确的语言进行推理。

方法

1. 收集术语。 从需求、代码库和用户自己的表述中，列出承载领域含义的名词和动词——也就是新手必须询问的概念。优先使用用户的原词，而不是你更喜欢的同义词。
2. 逐一定义。 用项目自己的语言写下一行定义，而不是词典释义。如果两个术语含义模糊，就明确区分，或将它们合并——此处的歧义会导致代码中的名称不一致。
3. 划定边界。 如果同一个词在系统的不同部分表示不同含义，那么这里就存在边界。为每个上下文命名，并注明其中包含哪些术语。一个词如果有两种含义，那就是两个术语。
4. 记录关键决策。 如果某项建模选择曾引发争议，或日后可能受到质疑，就写一份简短的决策记录：上下文、选择、被否决的备选方案，以及原因。

输出

• CONTEXT.md —— 共享语言术语表。每行一个术语： term - what it means in this project。如果有多个限界上下文，则按上下文分组。之后的每次会话都应参考此文件。重新运行时，添加新术语并更新已变更的定义；不要整体重写文件。
• 限界上下文草图 —— 列出各个上下文及其包含的术语，篇幅应短到能在十五秒内读完。
• 仅为有争议的建模决策编写决策记录，保存到 docs/decisions/NNNN-slug.md。先读取该目录，并从现有记录中的最高编号开始编号，避免两份记录编号冲突。显而易见的决策无需记录。

注意事项

• 术语表既是为模型准备的，也是为人准备的——应将其写成供模型加载的内容，而不是挂在墙上的说明。
• 不要编造项目中没有使用的术语。忠实反映领域，不要擅自改名。
• 保持术语表精简且及时更新。罗列一切却从不更新的术语表，还不如没有。删除已不再使用的术语。

适用场景

在新领域开始前运行此流程，先于 plan-interrogate；或者在 plan-interrogate 遇到无法确定含义的术语时，让它回到这里。此流程生成的 CONTEXT.md 与 plan-interrogate 生成的是同一个文件——一份共享语言文档，两种使用方式。