ddd-master

DDD Master

根据领域语言、边界和不变量定义或修订领域模型。在为新模型搭建脚手架前评估 DDD 是否适用；对于已有模型，复用已采纳的决策。

使用涵盖已更改模型或决策的分支。复用已有语言、上下文映射和时间线。阅读相关章节及其契约依赖；只有当契约密不可分时，才需要通读完整参考资料。

随附文件路径规则

相对于存放此 SKILL.md 的目录解析随附文件。写作 references/<name> 的路径对应 <ddd-master-dir>/references/<name>。

分支

当任务涉及……	相关章节
拒绝 DDD、贫血模型、事务脚本、口号式文件夹、CRUD 或遗留系统重写	references/when-not.md：三种判定、必要复杂性或遗留系统
EventStorming、事件时间线，或在上下文尚不存在时了解发生了什么	references/discovery.md：跳过／替换门槛、形式类别、Agent 实际做什么与伪装做什么
通用语言、子域、限界上下文、上下文映射或上下文关系	references/strategic.md：通用语言、上下文映射、关系决策树
聚合、值对象、领域事件、仓储、工厂或不变量	references/tactical.md：分类测试、一致性边界及受影响的构建块
规则密度、仓储 FAQ 或 Branas／Elemar 从业者检查	references/practitioner.md：密度、小型聚合或仓储 FAQ
默认采用 CQRS、复制“DDD”仓库、LLM 生成聚合，或模型与代码漂移	references/pitfalls.md：已诊断的建模或生成陷阱

对于新建或重新设计的模型，应逐一处理相关的发现、战略和战术决策。在既有上下文中的局部更改，只需处理受影响的不变量及其使用方。若要降级为分层架构，并且需要进行结构审计，可使用 architectural-analysis。

基本要求

1. 将新的上下文边界建立在组织的知识领域之上；局部更改应复用既有映射。
2. 将子域、限界上下文和可部署单元视为三个不同对象。
3. 一笔事务只更新一个聚合；其他聚合以标识的形式出现。
4. 将每个不变量放在根、值对象或领域服务上；仓储方法只负责加载、保存和搜索。
5. 命令成功后登记一个过去时态的领域事件；持久化后再发布。
6. 语言变更即模型变更。

步骤 1：判定

在搭建脚手架前，对新模型或重新设计的模型进行分类。仅在下列问题会影响决策时才使用它们；针对性问题或局部修复只需说明相关依据。

1. 标记必要复杂性（会一起变化的多步骤不变量），或写明“仅 CRUD + 语法”。
2. 将子域标记为核心、支撑性或通用。
3. 标记口号式 DDD：只有 Evans 术语或分层文件夹，却没有协作演进形成的规则模型。
4. 如果对象只是数据包，而规则由服务掌控，则标明为事务脚本（或记录之上的操作）。这种设计不要贴上 DDD 标签。
5. 如果更改位于一团乱麻之中，选择 Bubble、Autonomous Bubble 或 Open-host-over-ACL——如果请求是重写遗留系统，请先阅读 references/when-not.md 中的遗留系统章节，再做选择。
6. 将每条规则标记为语法、语义或生产规则。只有选择 Proceed 时，语义规则和生产规则才需要模型负责人；语法规则可保留在 UI 中。

记录 Refuse、Downgrade 或 Proceed。

完成标准： 方法及重要理由清晰明确。只记录会影响模型的分类；Refuse 和 Downgrade 不应搭建不必要的聚合或仓储类型。

第 2 步：掌握领域

仅当判定结果为 Proceed 且不存在可信的事件时间线时运行。用户要求进行 EventStorming 或询问“会发生什么”时，请阅读 references/discovery.md 中匹配的格式和引导环节。

1. 列出谁知道问题（代码、API、日志），以及谁知道答案（具名的人员）。没有答案提供者的地方会成为热点。
2. 在一条不设边界的时间线上，挂出过去时态的领域事件。优先使用句子形式的名称。
3. 按时间排序；从终点向回走一次；将空缺标记为红色热点。
4. 在每个事件之前立即放置一个现在时态的命令和一个执行者；如果原因未知，则放置一个热点。
5. 将意见分歧以双视图呈现。询问资金流向、成功指标和缺失角色；答案未知时保留热点。
6. 除非用户要求深入软件设计，否则在列出事件、命令和热点后停止。黄色便笺是聚合的候选项——其规则由第 4 步负责。
7. 划分松散耦合的子领域，并将关系类型交由第 3 步处理。

如果近期已有 EventStorm、Domain Storytelling 或 Example Mapping，则跳过工作坊工具——保留时间线产物，并从划分环节继续。只有当空缺与所请求的更改相关时，才重新开展探索。

*完成标准：*已形成一条按顺序排列的过去时态时间线；每个事件都有对应的命令／执行者或热点；人员名单或空缺已记录。

第 3 步：战略设计

创建或更改上下文边界或语言时运行。绘制上下文、确定语言或映射关系时，请阅读 references/strategic.md 中相关的语言或上下文映射章节。

1. 将每项具名能力分类为核心、支撑型或通用型。通用型需列出可采购或复用的候选项。
2. 搜索多义词（Customer、Order、Account）。将术语拆分到不同上下文中，或在一个具名上下文内赋予其单一含义。
3. 为每个逐渐成形的上下文确定通用语言：术语表、一个完整演练的场景，以及相符的代码名称。
4. 设计限界上下文。默认：一个核心上下文加一个上下文。当语言、目的、所有者或用途出现分歧时再拆分。为每个上下文命名（名称会成为语言的一部分）。
5. 绘制周边的上下文映射。每条边都要说明方向（上游／下游、相互依赖或自由）和一种主要模式。选择 ACL、OHS、顺从者、合作伙伴关系、共享内核、客户／供应商、已发布语言、各自为政或大泥球时，请使用 references/strategic.md 中的关系决策树。
6. 为 Agent 负责的每个上下文填写必需的画布单元格：名称、目的、UL 术语、入站或出站消息。

*完成标准：*每个具名区域都有子领域类型；每个范围内的上下文都有名称、目的和边界；每条相邻边都有方向和模式；必需的画布单元格均已填写。

步骤 4：设计一个聚合

仅对标记为 Domain Model 的有界上下文执行。设计构建块时，阅读 references/tactical.md 中受影响的构建块章节，并在适用时了解一致性与发布依赖。判断规则密度或仓库常见问题时，阅读 references/practitioner.md 中的 Density 或 Repository FAQ。

1. 为聚合命名，并说明其生命周期（计费周期、迭代或限定于某个流程）。
2. 列出真正的不变量——每次命令成功后都必须成立的规则。排除仅涉及关系的规则，以及“如果 Y 存在就不能删除 X”这类伪不变量。
3. 对每个概念进行分类：变化过程中保持身份 → 实体；可替换 / 按属性判断相等 → 值对象；拥有自身不变量和生命周期 → 通过 id 引用的其他聚合。
4. 画出一致性边界。每个边界内的对象都要说明它与根共享的不变量；每个边界外的对象都用 id 表示。
5. 选择根和写入 API。命令使用祈使形式；事件使用过去时。将它们配对。
6. 将跨对象不变量放在根上。本地的值对象 / 实体规则留在各自对象中。
7. 在应用服务（或领域服务）中、执行命令之前加载外部聚合。聚合不打开任何仓储。
8. 将每条跨聚合规则标记为事务性或最终一致，并说明由谁负责。最终一致：注册领域事件；在后续事务中更新另一个聚合。
9. 记录规模和冲突（命令速率 × 并发客户端数；图 / 事件随生命周期增长的情况）。当边界内的对象不再共享任何不变量时进行拆分。
10. 如果根需要全局写入权限，则使用一个仓储——它只接受此根，并加载 / 保存整个聚合簇。仅当构造过程会泄露内部类型或绕过不变量时才使用工厂。

完成条件： 每条变更路径都经过根；外部聚合都用 id 表示；每个值对象都是不可变的，且按组成部分判断相等；事件使用过去时，在操作成功后注册，并在持久化后发布；仓储（如有）仅接受此根；没有仓储方法承载业务规则。

警示信号

• 将标记为 ddd 的包或主题直接当作模型——检查根上的不变量和不可变值对象；否则写明“名义上的 DDD”，并根据领域专家建模。复制示例仓库时，阅读 references/pitfalls.md 中对应的章节。
• 多步骤提示词即将从聊天记录生成聚合或六边形架构——止步于术语表 / 事件列表 / 有界上下文提案；在生成其聚合之前，依据领域证据验证不确定的范围内上下文提案；复用已接受的边界。当循环是由大模型生成时，阅读 references/pitfalls.md 中对应的章节。
• 想通过事件存储或新建微服务来“做 DDD”——保留一个写模型和一个数据库；只有当某个明确命名的读取因聚合约束而受阻时，才拆分查询模型。若有人提议默认采用 CQRS 或事件溯源，阅读 references/pitfalls.md 中对应的章节。
• 某个 *Service 即将拥有新的不变量——将规则放在实体或值对象上；应用服务使用动词命名。
• 将六边形端口当作 DDD 的证明——六边形架构 + 事务脚本是有效的降级方案；战术 DDD 仍要求上下文内有 Domain Model。