ddd-aggregates

name	ddd-aggregates
description	从不变量出发设计聚合边界：聚合根、实体、值对象、事务边界与跨聚合一致性策略。
risk	safe
source	self
tags	[ddd, tactical, aggregates, invariants]
date_added	2026-05-08

DDD Aggregates

🌐 English version: English

使用时机

• 限界上下文与集成策略已就绪，需要设计上下文内部的构造块。
• 需要回答"哪些对象必须一起变更以保持一致性"。
• ddd-model-review 报告"不变量表达率 < 60%"，或 ddd-domain-interactions 报告"事件需携带另一聚合私有数据"时，作为回溯目标重新执行。

输入要求

• 必需：事件流与命令候选（来自 ddd-discover）、上下文目录与词汇表（来自 ddd-contexts）。
• 可选：上下文映射与失败模式（来自 ddd-context-map）。

流程

1. 提取不变量：从命令与事件中提取"必须始终为真"的业务规则（不变量）。
2. 聚类对象：以不变量为纽带，将对象聚类为聚合候选；明确聚合根（唯一外部入口）。
3. 识别构造块：区分聚合内的实体（有标识、有生命周期）与值对象（无标识、不可变、按值比较）。
4. 定义边界规则：外部只持有聚合根引用；跨聚合引用使用 ID；每个聚合是一个事务边界。
   • 外部引用再审视：对模型中每一个"外部引用对象"（foreign reference），再问一遍——我们自己是否需要管理它的生命周期（创建、修改、终结）？若答案为是，它应被提升为 内部聚合，而不是仅保留 ID 引用。典型触发器：参考数据类对象（港口目录、日历、线路目录）若由我方维护，必须列为聚合。
   • Specification 模式识别：当某条业务规则以"给定 X，X 是否满足 Y"的谓词形式出现（如 isSatisfiedBy(Itinerary)），显式抽取为 Specification，而不是塞进工厂或服务内部的 if 分支。
5. 命令边界：为每个聚合定义它处理的命令、前置验证、副作用。
6. 跨聚合一致性：聚合内强一致；聚合间最终一致——定义事件驱动 / 补偿 / 重试策略。
7. 仓储接口草案：为每个聚合产出仓储接口的语义定义（方法名 + 语义，不含代码实现）。

输出

工件	结构要求
聚合目录	表格：聚合名、聚合根、包含实体、包含值对象、关键不变量、关键命令
不变量表	表格：不变量、触发命令、校验位置、违反时行为
实体与值对象清单	表格：名称、类型（Entity/VO）、所属聚合、标识策略/相等性定义
事务边界说明	列表：默认规则、例外条件、并发/锁策略
跨聚合一致性策略	表格：场景、触发事件、补偿方式、幂等保障、重试策略
仓储接口草案	表格：聚合、方法、语义说明、查询边界

校验清单

• 每个聚合至少对应 1 条显式不变量
• 聚合边界说明了事务边界；默认"1 个事务修改 1 个聚合"
• 跨聚合一致性有事件与补偿策略
• 无"以外键划聚合"的反模式（聚合不是 ORM 关系映射）
• 实体与值对象的区分有明确理由（标识 vs 值语义）
• 聚合大小合理：单个聚合不应包含 > 5 个实体（若超过需论证）
• 每个外部引用都已回答过"其生命周期是否由我方管理"；答案为是者已提升为内部聚合
• 已扫描"谓词型业务规则"并评估 Specification 模式；入选者已列为一等构造块

回溯触发

• 不变量跨越多个上下文 → 回溯至 ddd-contexts（一致性需求被边界割裂）。
• 被 ddd-domain-interactions 触发：事件需携带另一聚合私有数据，说明聚合边界需调整。
• 被 ddd-model-review 触发：不变量表达率 < 60%（聚合可能是数据容器而非行为边界）。

示例

@ddd-aggregates
基于以下上下文定义和事件流，帮我设计 Booking 上下文内的聚合：
- 上下文：Booking（预订全生命周期）
- 核心术语：Booking, TimeSlot, BookingPolicy, CheckIn
- 关键事件：BookingRequested, BookingConfirmed, BookingCancelled, CheckInRecorded
请输出聚合目录、不变量表、实体/值对象清单与事务边界说明。