聚合根的选择策略：如何识别聚合根，避免贫血模型与过大聚合

聚合根（Aggregate Root）是领域驱动设计中事务一致性的边界守卫。选错聚合根会导致两个极端：贫血模型（业务逻辑散落在 Service 中）或过大聚合（单次事务锁住过多数据，性能崩塌）。本节提供一套可操作的识别策略与校验清单。

3.1 聚合根的核心职责

聚合根不是“实体列表的管理员”，而是业务不变量的守护者。它必须满足以下三条硬约束：

3.2 四步识别法

以下方法从业务事件出发，逐步收敛到聚合根候选，避免凭直觉拍脑袋。

1. 列出业务事件 —— 从 Event Storming 或用例中提取所有“用户触发”或“系统触发”的事件，例如“订单已提交”“库存已锁定”。
2. 找出被修改的数据 —— 每个事件对应一组被创建、更新或删除的数据对象，将这些对象圈在一起。
3. 标记事务一致性需求 —— 哪些数据必须同时更新或同时不更新？如果允许最终一致，则拆成不同聚合。
4. 验证不变量归属 —— 对每个候选聚合根，问：“如果去掉这个根，业务规则还能被强制吗？” 不能则保留。

3.3 避免贫血模型：聚合根必须承载行为

贫血模型的典型特征是聚合根只有 getter/setter，业务逻辑全部放在 XXXService 中。判断标准很简单：如果聚合根的方法列表与属性列表几乎一样长，就是贫血模型。

// 贫血模型 —— 不推荐
public class Order {
    private String status;
    public String getStatus() { return status; }
    public void setStatus(String status) { this.status = status; }
}

// 充血模型 —— 推荐
public class Order {
    private OrderStatus status;
    public void submit() {
        if (this.status != OrderStatus.DRAFT) {
            throw new IllegalStateException("只有草稿订单可以提交");
        }
        this.status = OrderStatus.SUBMITTED;
        // 触发领域事件
        DomainEventPublisher.publish(new OrderSubmittedEvent(this.id));
    }
}

3.4 避免过大聚合：按事务边界拆分

过大聚合的典型症状：一个聚合包含 10 个以上实体、单次加载需要 5 张表 JOIN、事务锁冲突频繁。拆分的核心原则是“一个聚合只保证一个业务不变量”。

以下场景建议拆分：

• 独立生命周期 —— 子实体可以脱离聚合根单独创建或删除（例如“评论”可以脱离“文章”聚合，因为评论有自己的生命周期）。
• 不同变化频率 —— 部分数据每天更新多次，部分数据每月更新一次，放在一起会导致不必要的锁竞争。
• 跨限界上下文 —— 如果两个实体属于不同的限界上下文（如“订单”和“库存”），它们天然不应在同一个聚合内。

3.5 聚合根粒度校验清单

完成初步识别后，使用以下清单逐项检查，避免遗漏或过度设计：

3.6 典型反模式与修正

以下是团队实践中反复出现的三种错误模式，以及对应的修正方案：

• 上帝聚合 —— 一个聚合包含所有关联数据（如 Order 包含 User、Address、Payment、Logistics）。
  修正：按事务一致性拆分为 Order、Payment、Logistics 三个独立聚合，通过 OrderId 关联。
• 数据袋子聚合 —— 聚合根只有 add/remove/get 方法，业务逻辑在 Service 中。
  修正：将 Service 中的业务规则（如“订单金额超过 10000 需要审批”）移到聚合根的 submit() 方法中。
• 隐形聚合根 —— 没有显式定义聚合根，所有实体都是独立的 Repository。
  修正：从业务不变量出发，找到“拥有最多不变量”的实体作为聚合根，其他实体降级为子实体。