4. 聚合（Aggregate）设计：聚合根的选择、聚合边界划分、事务一致性与最终一致性权衡

聚合是领域驱动设计中用于封装业务不变条件（Invariant）的核心模式。它将一组具有紧密关联、必须保持数据一致性的实体和值对象组合为一个整体，通过聚合根（Aggregate Root）作为外部访问的唯一入口。错误的聚合设计会导致事务范围过大、性能瓶颈或数据不一致。本节将系统讲解聚合根的选择原则、边界划分方法以及一致性策略的权衡。

4.1 聚合根的选择原则

聚合根是聚合中唯一能被外部引用的实体，负责维护聚合内部的不变条件。选择聚合根需遵循以下原则：

4.2 聚合边界划分方法

聚合边界划分的核心是识别哪些对象必须保持强一致性，哪些可以接受最终一致性。以下是三种常用的边界划分策略：

1. 基于不变条件（Invariant）：列出所有业务规则，将必须同时满足的规则所涉及的对象划入同一聚合。例如“订单总金额必须等于所有订单行金额之和”，则订单与订单行必须在同一聚合内。
2. 基于事务范围：分析业务操作中需要原子性提交的数据变更范围。如果一个操作需要同时更新 A 和 B 才能保证业务正确，则 A 和 B 应属于同一聚合。
3. 基于引用频率：如果两个实体在绝大多数业务场景中总是同时被加载和修改，则考虑合并为一个聚合；如果它们经常被独立访问，则应拆分为不同聚合。

下图展示了审批流系统中聚合边界的典型划分：

4.3 事务一致性与最终一致性权衡

聚合设计中最关键的决策是确定哪些操作需要强事务一致性，哪些可以接受最终一致性。错误的权衡会导致系统性能下降或数据错误。

4.4 一致性策略选择决策树

在实际建模中，可通过以下决策树快速判断应采用哪种一致性策略：

4.5 实战案例：审批流中的一致性设计

以审批流中“审批通过”操作为例，展示一致性策略的具体应用：

// 聚合根：ApprovalOrder
public class ApprovalOrder extends AbstractAggregateRoot<ApprovalOrderId> {
    private List<ApprovalNode> nodes;
    private OrderStatus status;
    
    public void approve(String nodeId, String userId) {
        // 1. 校验当前节点是否可审批（不变条件）
        ApprovalNode currentNode = findCurrentNode();
        if (!currentNode.canApprove(userId)) {
            throw new BusinessException("当前用户无权审批此节点");
        }
        
        // 2. 更新节点状态（聚合内强一致性）
        currentNode.setStatus(NodeStatus.APPROVED);
        currentNode.setApprover(userId);
        currentNode.setApprovedAt(LocalDateTime.now());
        
        // 3. 判断是否所有节点已完成
        if (allNodesCompleted()) {
            this.status = OrderStatus.COMPLETED;
        }
        
        // 4. 发布领域事件（跨聚合最终一致性）
        registerEvent(new ApprovalCompletedEvent(this.id, nodeId, userId));
    }
}

// 事件处理器（异步）
@EventListener
public void handleApprovalCompleted(ApprovalCompletedEvent event) {
    // 发送通知（最终一致性）
    notificationService.sendApprovalNotification(event.getOrderId());
    // 更新统计（最终一致性）
    statisticsService.updateApprovalMetrics(event.getOrderId());
}

4.6 聚合设计常见陷阱

• 巨型聚合（God Aggregate）：将过多对象放入同一聚合，导致事务范围过大、并发冲突严重。应遵循“小聚合”原则，只包含必须强一致的对象。
• 贫血聚合根：聚合根只作为数据容器，不包含业务逻辑。应确保聚合根包含所有与不变条件相关的业务方法。
• 跨聚合对象引用：在聚合内直接持有其他聚合的对象引用，导致边界模糊。应只通过 ID 引用其他聚合。
• 忽视最终一致性窗口：在跨聚合场景中未考虑短暂的不一致状态，导致业务判断错误。应在业务层面设计补偿或重试机制。