聚合的设计原则：一致性边界、事务边界、生命周期管理

聚合（Aggregate）是领域驱动设计中用于封装业务不变量的核心构造。设计一个合理的聚合，需要同时平衡三个维度：一致性边界确保业务规则不被破坏，事务边界保障数据完整性，生命周期管理控制聚合的创建、变更与持久化。本章将逐一拆解这三个原则，并给出可落地的设计指引。

2.1 一致性边界：聚合的“宪法”

一致性边界定义了聚合内部所有实体和值对象必须共同遵守的业务规则。边界内的任何状态变更，都不能违反聚合根所维护的不变量。

以下表格对比了强一致性与最终一致性的适用场景：

设计一致性边界时，应遵循以下步骤：

1. 识别不变量：与领域专家确认哪些规则是“必须永远为真”的。
2. 划定边界：将需要同时满足不变量的对象归入同一聚合。
3. 验证边界：通过事件风暴或场景推演，检查边界是否过大或过小。

2.2 事务边界：一次提交，一个聚合

事务边界与一致性边界紧密相关。DDD 的核心原则是：一个事务只修改一个聚合实例。这意味着，聚合根是事务的原子操作单元。

事务边界的设计决策直接影响系统的并发能力和数据一致性：

• 单聚合事务：使用数据库本地事务，保证 ACID，适合强一致性场景。
• 跨聚合事务：使用 Saga（编排或协同），保证最终一致性，适合高吞吐场景。
• 事件驱动：聚合发布领域事件，其他聚合异步响应，实现松耦合。

以下代码展示了一个聚合根如何通过仓储接口保证事务边界：

// 聚合根：订单
public class Order : AggregateRoot<OrderId>
{
    private List<OrderItem> _items = new();
    public IReadOnlyList<OrderItem> Items => _items.AsReadOnly();
    public Money TotalAmount { get; private set; }

    public void AddItem(ProductId productId, int quantity, Money unitPrice)
    {
        // 业务不变量：数量必须大于0
        if (quantity <= 0)
            throw new DomainException("数量必须大于0");

        var item = new OrderItem(productId, quantity, unitPrice);
        _items.Add(item);
        RecalculateTotal();
    }

    private void RecalculateTotal()
    {
        TotalAmount = new Money(_items.Sum(i => i.SubTotal.Amount));
    }
}

// 仓储接口：保证一次只持久化一个聚合
public interface IOrderRepository : IRepository<Order, OrderId>
{
    Task<Order> GetByIdAsync(OrderId id);
    Task AddAsync(Order order);
    Task UpdateAsync(Order order);
}

2.3 生命周期管理：从创建到归档

聚合的生命周期包括创建、状态变更、持久化、归档或删除。良好的生命周期管理能防止聚合处于非法状态，并简化 API 契约的设计。

生命周期管理通常包含以下阶段：

2.4 三条原则的协同关系

一致性边界、事务边界和生命周期管理并非孤立的原则，而是相互支撑的三角关系：

• 一致性边界决定了哪些对象属于同一个聚合，是事务边界和生命周期管理的基础。
• 事务边界保障了一致性边界内的操作是原子的，防止部分更新导致数据不一致。
• 生命周期管理确保聚合在整个生命周期内都遵循一致性边界定义的规则，从创建到归档都不例外。