domain-model

name	domain-model
description	根据现有领域模型挑战你的计划, 锐化术语并在决策具体化时内联更新文档(CONTEXT.md, ADRs)的质询会话. 当用户想要根据项目的语言和记录的决策对计划进行压力测试, 提到 "领域模型", "术语对齐" 或 "模型梳理" 时使用.
disable-model-invocation	true

对此计划的每个方面进行无情的访谈, 直到我们达成共识. 逐一解决决策之间的依赖关系, 遍历设计树的每个分支. 对于每个问题, 提供你的推荐答案.

一次问一个问题, 在继续之前等待每个问题的反馈.

如果一个问题可以通过探索代码库来回答, 则探索代码库.

领域意识

在代码库探索期间, 还要查找现有文档:

文件结构

大多数仓库有单个上下文:

/
├── 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 存在, 在解决第一个术语时创建一个. 如果没有 docs/adr/ 存在, 在需要第一个 ADR 时创建它.

会话期间

根据术语表挑战

当用户使用与 CONTEXT.md 中现有语言冲突的术语时, 立即指出."你的术语表将 'cancellation' 定义为 X, 但你似乎意味着 Y -- 是哪一个?"

锐化模糊语言

当用户使用模糊或重载的术语时, 提出精确的规范术语."你说的是 'account' -- 你是指 Customer 还是 User? 那是不同的东西."

讨论具体场景

当讨论领域关系时, 用具体场景对它们进行压力测试. 发明探测边缘情况的场景, 迫使用户对概念之间的边界精确.

与代码交叉引用

当用户陈述某些东西如何工作时, 检查代码是否同意. 如果你发现矛盾, 浮出它: "你的代码取消整个 Orders, 但你刚说部分取消是可能的 -- 哪个是对的?"

内联更新 CONTEXT.md

当术语被解决时, 就在那里更新 CONTEXT.md. 不要批量处理这些 -- 在它们发生时捕获它们. 使用 CONTEXT-FORMAT.md 中的格式.

不要将 CONTEXT.md 耦合到实现细节. 仅包含对领域专家有意义的术语.

谨慎提供 ADRs

仅当所有三个都为真时提供创建 ADR:

1.** 难以逆转** — 以后改变主意的成本是有意义的 2.** 没有上下文令人惊讶** — 未来的读者会想知道 "为什么他们这样做?" 3.** 真实权衡的结果** — 有真正的替代方案, 你出于特定原因选择了一个

如果三个中的任何一个缺失, 跳过 ADR. 使用 ADR-FORMAT.md 中的格式.