聚合设计指南：大小、边界与事务一致性

概述

系列定位说明

本文是"领域驱动设计与业务架构"系列的第 8 篇，聚焦于 聚合设计 这一战术 DDD 中最为棘手的主题。在本系列前序文章中，我们已经建立了战术 DDD 的基本实现模式（第 2 篇《战术 DDD 与 Spring 实现：聚合、资源库与领域服务》），探讨了事件驱动与 CQRS（第 4 篇）、Axon Event Sourcing 的编程模型（第 6 篇），以及通过防腐层隔离外部模型的策略（第 7 篇）。然而，实际项目中聚合设计的核心挑战始终不是"如何用 JPA 写一个 @Entity"，而是"聚合到底该划多大"------边界太大则性能恶化、并发冲突加剧；边界太小则事务边界不完整，业务一致性难以保证。

本文将聚合设计的四项核心原则（小聚合、通过 ID 引用其他聚合、一次事务只修改一个聚合实例、最终一致性处理跨聚合操作）作为理论基石，通过对聚合大小与边界的量化分析、拆分与合并的决策框架，以及与 CQRS/Event Sourcing 的协同，系统揭示 如何在业务准确性与系统性能之间为聚合找到最佳平衡点。全文以电商订单系统的聚合设计演进为贯穿案例，展示从最初的大聚合逐步拆分到最终通过领域事件保障一致性的完整推理过程与 Spring 代码实现。

---

总结性引言

电商系统的第一个版本，我们本着"简单直观"的理念，将订单、订单项、用户、产品、支付信息全部塞进了一个 Order 聚合，理由很充分："他们总是一起使用"。然而上线不久，问题接踵而至：并发更新订单状态时 @Version 冲突如潮水般涌来；加载一个订单要关联五六张表，慢查询拖垮了后台页面；更荒唐的是，修改一下收货地址，居然也要和库存扣减争抢同一把乐观锁。这就是聚合过大的代价。

于是我们开始拆分：把 Product、User 独立成各自的聚合，Order 只保留 userId 和 productId；引入领域事件，订单确认后异步扣减库存，用最终一致性接受短暂的不一致窗口。但拆分又带来了新的难题：订单确认和库存扣减不再是一个本地事务，如何才能不超卖？订单取消后，退款与库存回补又如何编排？聚合太小，事务边界不完整，分布式事务的复杂度令人望而却步。

聚合设计没有"标准答案"，有的只是针对特定业务场景的深度权衡。本文将从大聚合的痛点出发，沿着"发现问题 → 分析写入足迹 → 拆分与合并决策 → 最终一致性保障"的路径，提供一套可复用的聚合大小评估方法和工程决策框架，并给出可在 Spring 中直接落地的代码实践。

---

核心要点

• 小聚合优先：一个聚合通常只包含 1～5 个实体，避免大聚合带来的锁竞争和加载性能问题。
• ID 引用其他聚合 ：Order 持有 productId 而非 Product 对象，写操作绝不跨聚合级联，关联数据由应用层显式加载。
• 一次事务只修改一个聚合 ：@Transactional 边界严格与聚合边界对齐，跨聚合操作必须通过领域事件实现最终一致。
• 拆分/合并决策框架：通过写入足迹分析、锁冲突率、独立查询频率、业务耦合度等指标，科学决定聚合边界。
• 不变量集中保护 ：所有业务规则校验内聚在聚合根方法中，杜绝 setStatus() 等暴露内部状态的贫血模式。

---

文章组织架构图

flowchart TD A["聚合设计的四项核心原则"] --> B["小聚合优先：量化依据与反例分析"] A --> C["聚合间ID引用与显式加载"] A --> D["一次事务只修改一个聚合"] A --> E["跨聚合最终一致性策略"] B --> F["聚合拆分与合并决策框架"] C --> F D --> E E --> G["聚合不变量保护"] F --> G G --> H["聚合与CQRS/Event Sourcing协同"] H --> I["贯穿案例：电商订单聚合演进"] I --> J["与前后系列衔接"] J --> K["面试高频专题"] classDef default fill:#f1f5f9,stroke:#334155,stroke-width:1.5px,color:#1e293b

图说明：

1. 层级关系：四项原则构成理论的根节点，所有具体设计方法由此衍生。量化分析与ID引用指导拆分决策，事务边界约束催生最终一致性策略。
2. 模块定位：拆分/合并框架是连接理论原则与工程实践的"转换器"，不变量保护是聚合内部质量的守门员。
3. 协同视角：CQRS/Event Sourcing 对聚合提出更高要求，也提供了更大灵活性，该模块展示二者如何配合。
4. 收束：贯穿案例将零散知识点串联为完整的演进故事，面试专题提炼文中核心权衡，达到学以致用。

---

1. 聚合设计的四项核心原则

Eric Evans 在《领域驱动设计》中引入聚合模式，旨在为关联紧密的对象群定义清晰的边界，并选择唯一根实体（聚合根）作为外部访问的入口。Vaughn Vernon 在《实现领域驱动设计》第 10 章中将其提炼为四项可操作原则：

1. 在聚合边界内保护业务不变量：所有对聚合内部状态的修改，都必须通过聚合根暴露的方法进行，并在此方法内完成不变量的校验。
2. 设计小聚合：倾向较小的聚合，以减少事务范围和并发冲突。每个聚合尽可能只包含一个或少数几个实体。
3. 通过唯一标识引用其他聚合：聚合间不应持有对象引用，更不要使用 ORM 的级联映射，而应仅存放全局唯一 ID。
4. 使用最终一致性更新其他聚合：一次事务只修改一个聚合实例的状态；若业务需要跨聚合修改，则通过领域事件异步完成，并接受短暂的最终一致。

这四项原则并非彼此独立，而是相互约束：小聚合迫使通过 ID 引用（原则 3），ID 引用又使得跨聚合的同步事务变得不可能，从而必须依赖最终一致性（原则 4）。本系列第 2 篇已经演示了聚合根的基本实现（@Entity、不变量方法），本文将在此基础上深入探讨"设计小聚合"这一最具挑战的权衡。

---

2. 小聚合优先：量化依据与反例分析

2.1 聚合大小的衡量指标

聚合大小的评估不能仅凭直觉，需要引入以下可量化指标：

• 实体数量 ：聚合内包含的实体（含值对象集合）个数。经验值通常 不超过 3～5 个 。例如 Order 聚合可能包含 Order（根）、OrderItem（值对象集合）、ShippingAddress（值对象），即 1 个实体 + 若干值对象。
• 加载 SQL 的 JOIN 次数 ：在一个聚合的 Repository 中，加载完整聚合所需的最大表连接数。若聚合过大，JPA 可能产生 5 次以上的 JOIN 或导致 N+1 查询。建议 不超过 5 次 JOIN。
• 字段数量（宽表效应）：若聚合根对应一张宽表，字段超过 50 个且部分字段很少被访问，意味着实体间职责混淆，应考虑拆分。

2.2 大聚合的后果分析

案例背景 ：电商系统初版的 Order 聚合包含了 User、Product、Payment 等信息，采用 JPA 的 @ManyToOne 和 @OneToMany 级联：

// 大聚合反模式
@Entity
public class Order {
    @Id private Long orderId;
    @ManyToOne(cascade = CascadeType.ALL)
    private User user;
    @OneToMany(cascade = CascadeType.ALL, orphanRemoval = true)
    private List<OrderItem> items;
    @ManyToOne(cascade = CascadeType.ALL)
    private Payment payment;
    // ...
}

性能问题：

• 加载性能差 ：每次加载 Order，JPA 默认会根据 @ManyToOne 的 FetchType.EAGER 或懒加载触发额外的 SELECT，很容易导致 N+1 查询。即便通过 JOIN FETCH 优化，Order JOIN User JOIN Payment JOIN Product ... 产生 5～6 次 JOIN，SQL 执行时间激增，返回大量冗余数据。
• 并发冲突高 ：聚合根使用 @Version 乐观锁进行并发控制。大聚合中任何一部分的变化（如修改收货地址、添加订单项）都会递增版本号。若订单状态更新和收货地址修改同时发生，一方会因版本冲突而失败。在大促期间，库存扣减和订单备注修改竟要竞争同一把锁，造成大量重试，吞吐量急剧下降。
• 事务范围过大：事务包裹了整个大聚合，长事务占用数据库连接，增加死锁风险。

2.3 聚合过小的问题

如果把一切实体都拆为独立聚合，看似灵活，实则会导致 事务边界不完整：

• 不变量无法在单一事务中保护 ：例如订单确认时，需要校验"用户已支付且库存充足"。若 Order 和 Inventory 是两个聚合，无法在一个本地事务内同时锁定订单状态并扣减库存，必须引入分布式事务（如 XA）或最终一致性方案。
• 分布式事务复杂度：分布式事务性能低、锁粒度大、失败恢复困难。多数情况下，宁愿接受短暂的不一致，用最终一致性换取性能和可用性。
• 业务语义割裂 ：某些概念在业务上天然不可分。若把 OrderItem 从 Order 中拆出，就破坏了"订单总额是所有订单项之和"这一不变量，外部可以绕过 Order 直接修改 OrderItem.price，导致数据不一致。

2.4 聚合大小与性能/一致性权衡图

xychart-beta
    title "聚合大小与性能/一致性权衡"
    x-axis "聚合大小（实体数）" 1 --> 10
    y-axis "性能（吞吐量）" 0 --> 100
    y-axis "一致性保障难度" 0 --> 100
    line "并发性能" [10, 80, 95, 100, 95, 80, 60, 40, 20, 10]
    line "事务完整性" [20, 60, 85, 95, 98, 99, 99, 100, 100, 100]

图说明：

1. 并发性能（实线）：聚合极小时，频繁的跨聚合协调（事件、补偿）降低了有效吞吐；聚合逐渐增大，事务边界趋于完整，协调开销减少，但过大时锁冲突和加载开销再次压低性能。曲线呈倒 U 型。
2. 事务完整性（虚线）：聚合越大，单体事务能覆盖的不变量越多，完整性越高；但大聚合也会诱发长事务，反而可能破坏一致性。理论上一直上升，但现实中过大的聚合往往因性能问题被拆分。
3. 平衡区域：峰值附近（通常 2～5 个实体）是理想区间，既能保障核心不变量的即时一致性，又不会过度牺牲并发能力。
4. 决策启示：聚合设计是在这两个维度间寻找具体业务可接受的折中点，没有绝对的最优解。

2.5 写入足迹分析方法

最科学的聚合大小确定方法，源自 Vaughn Vernon 的 写入足迹 概念：

• 步骤：收集所有需要修改数据的业务用例（如"用户下单"、"商家发货"、"用户取消订单"），记录每个用例涉及修改的实体及属性。
• 绘制写入足迹矩阵：如果大部分写操作仅涉及聚合的一部分实体，而那些未涉及的实体又无业务不变量要求，则这部分实体可考虑拆分为独立聚合。
• 示例 ：订单系统中，"用户修改收货地址"只写 shippingAddress，"卖家发货"只写 logisticsInfo，它们与订单核心状态（status）和订单项并无不变量依赖，因此shippingAddress 和 logisticsInfo 可以留在 Order 聚合内作为值对象，甚至物流信息频繁独立查询时还可以进一步拆分到 Shipment 聚合。而"订单确认"必须同时校验订单状态和库存，此时库存应独立，由领域事件处理。

---

3. 聚合间 ID 引用与显式加载

3.1 设计模式与代码对比

大聚合方式（错误）：

@Entity
public class Order {
    @Id private Long orderId;
    @ManyToOne
    private User user; // 对象引用
    @ManyToOne
    private Product product;
    // ...
}

这种设计会诱使开发者写出 order.getUser().getName() 这样的链式导航，进而导致 JPA 懒加载或级联更新，完全模糊了聚合边界。

正确方式------ID 引用：

@Entity
public class Order {
    @Id private Long orderId;
    private Long userId;       // 外部聚合ID
    // OrderItem 是值对象，属于本聚合
    @ElementCollection
    private List<OrderItem> items;
    private String shippingAddress;
    // 不变量方法
    public void confirm() {
        if (this.status != OrderStatus.PENDING) {
            throw new OrderDomainException("只能确认待支付订单");
        }
        this.status = OrderStatus.CONFIRMED;
        // 注册事件
        registerEvent(new OrderConfirmed(this.orderId, this.userId, this.totalAmount));
    }
}

Order 只持有 userId，不持有 User 对象。@ElementCollection 将 OrderItem 作为聚合内部值对象持久化到关联表，但不跨越聚合边界。

3.2 应用层显式加载

当应用层需要展示订单详情（包含用户昵称、产品名称）时，应通过 Repository 显式加载：

@Service
public class OrderQueryService {
    private final OrderRepository orderRepository;
    private final UserRepository userRepository;
    private final ProductRepository productRepository;

    public OrderDetailDTO getOrderDetail(Long orderId) {
        Order order = orderRepository.findById(orderId)
                .orElseThrow(() -> new OrderNotFoundException(orderId));
        User user = userRepository.findById(order.getUserId())
                .orElseThrow(() -> new UserNotFoundException(order.getUserId()));
        // 从OrderItem中提取productId列表，批量加载产品信息
        List<Long> productIds = order.getItems().stream()
                .map(OrderItem::getProductId)
                .collect(Collectors.toList());
        List<Product> products = productRepository.findAllById(productIds);
        return OrderAssembler.toDTO(order, user, products);
    }
}

序列图：

sequenceDiagram participant Client participant OrderQueryService participant OrderRepository participant UserRepository participant ProductRepository Client->>OrderQueryService: getOrderDetail(orderId) activate OrderQueryService OrderQueryService->>OrderRepository: findById(orderId) OrderRepository-->>OrderQueryService: Order OrderQueryService->>UserRepository: findById(order.getUserId()) UserRepository-->>OrderQueryService: User OrderQueryService->>ProductRepository: findAllById(productIds) ProductRepository-->>OrderQueryService: List OrderQueryService-->>Client: OrderDetailDTO deactivate OrderQueryService

图说明：

1. 职责分离：查询服务仅负责数据组装，没有任何修改操作，无需事务，性能最佳。
2. 聚合边界清晰 ：Order 的写操作不会触及 User 或 Product，各自的生命周期完全解耦。
3. 懒加载替代：相比于 JPA 的懒加载（可能造成 N+1），显式加载的意图更清晰，且可利用批量查询优化。
4. 后续扩展：该查询逻辑可进一步迁移到 CQRS 的读模型，直接通过 SQL 或物化视图实现跨聚合联表，完全不用理会聚合边界。

---

4. 一次事务只修改一个聚合的工程保障

4.1 事务边界严格对齐

应用服务是事务的理想边界：

@Service
@Transactional
public class OrderApplicationService {
    private final OrderRepository orderRepository;

    public void confirmOrder(Long orderId) {
        Order order = orderRepository.findById(orderId)
                .orElseThrow(() -> new OrderNotFoundException(orderId));
        order.confirm();  // 内部发布 OrderConfirmed 事件
    }
}

在该方法中，仅有 Order 聚合被修改。严禁 在同一个事务方法中直接修改其他聚合的 Repository：

// 反模式：在一个事务中同时修改订单和库存
@Transactional
public void confirmOrderAndDeductStock(Long orderId) {
    Order order = orderRepository.findById(orderId);
    order.confirm();
    Inventory inventory = inventoryRepository.findById(inventoryId);
    inventory.deduct(quantity);
    inventoryRepository.save(inventory); // 跨聚合事务
}

4.2 反模式分析

上述写法在单体应用中看似方便，实则埋下巨大隐患：

• 事务边界模糊：本应属于两个不同聚合的业务逻辑耦合在一个事务内，任何一方的需求变动都要修改这个服务，违反单一职责。
• 锁竞争扩大 ：Inventory 和 Order 两把乐观锁被同时占用，加剧冲突。
• 微服务拆分阻碍：未来若将订单和库存拆分为不同微服务，该方法必须改成分布式事务，重构成本极高。

4.3 跨聚合操作的正确处理：拆分为同步核心 + 异步次要

若业务用例本质上是"订单确认 + 库存扣减"，必须识别出核心操作并拆分：

• 核心（必须同步）：订单状态从 PENDING 转为 CONFIRMED，这是本聚合的责任。
• 次要（可异步）：库存扣减。订单确认事件发布后，由库存服务消费并扣减。

拆分后，库存扣减失败不会影响订单已确认的事实，可通过补偿逻辑（如取消订单）来处理。这种模式正是下一节最终一致性的基础。

---

5. 跨聚合操作的最终一致性策略

5.1 事件驱动编排

// Order 聚合内部发布事件
public void confirm() {
    // 不变量检查 ...
    this.status = OrderStatus.CONFIRMED;
    registerEvent(new OrderConfirmed(this.orderId, this.items));
}

在应用服务中，Spring 的 ApplicationEventPublisher 或 Axon 的 EventGateway 在事务提交后发布事件，确保事件一定在聚合修改持久化后发送。

事件消费方------库存服务：

@Component
public class InventoryEventHandler {
    private final InventoryRepository inventoryRepository;

    @EventListener
    @Transactional
    public void on(OrderConfirmed event) {
        for (OrderItem item : event.getItems()) {
            Inventory inventory = inventoryRepository.findById(item.getProductId())
                .orElseThrow(...);
            inventory.deduct(item.getQuantity());
        }
    }
}

库存扣减如果失败（如库存不足），可发布 InventoryDeductFailed 事件，触发补偿流程：

@EventListener
public void on(InventoryDeductFailed event) {
    // 补偿：取消订单
    Order order = orderRepository.findById(event.getOrderId());
    order.cancel("库存不足");
}

5.2 流程图：跨聚合最终一致性

flowchart TB A[客户端请求下单] --> B[Order应用服务
确认订单] B -->|1. 更新Order状态| C[(订单数据库)] B -->|2. 发布OrderConfirmed| D[消息队列/事件总线] D --> E[库存服务消费事件] E -->|扣减库存| F{扣减成功?} F -->|是| G[(库存表更新)] F -->|否| H[发布InventoryDeductFailed] H --> I[补偿服务
取消订单/退款] I --> J[订单状态回滚]

图说明：

1. 异步解耦：订单服务只负责自己的事务，完成后发送事件即可立即返回，响应迅速。
2. 失败处理：库存扣减失败通过补偿事件触发订单取消，形成正向流程+反向补偿的 Saga 模式。
3. 幂等要求：事件消费方必须实现幂等，防止重复投递导致多扣库存。可使用事件 ID 去重表。
4. 最终一致窗口：从订单确认到库存真正扣减存在短暂延迟，此时前端可显示"订单处理中"状态，或通过 WebSocket 推送最终结果。

5.3 结合 Axon Saga 或纯 Spring 事件

• Axon Saga ：对于复杂长事务（如订单、支付、库存、物流多步），可使用 Axon 的 @Saga 注解管理状态和补偿。本系列第 6 篇有详细用法。
• 纯 Spring 事件 + 本地事件表：在单体或未引入 Axon 的项目中，可以仿照 outbox 模式（本系列第 5 篇），将事件持久化到同一数据库，利用事务提交保证发布，消费方轮询事件表，简单可靠。

---

6. 聚合拆分与合并的决策框架

6.1 拆分信号（满足任意一个应评估拆分）

• 独立查询需求：聚合内某部分实体频繁被单独查询，例如订单的物流信息经常被独立查看和更新，且不与订单状态直接交互。
• 乐观锁冲突集中 ：聚合内某字段频繁更新（如库存 quantity），而其他字段很少变化，导致大量版本冲突。拆分后各自拥有独立的版本控制。
• 业务规则变更频率差异大 ：Order 的核心流程稳定，而 Promotion 促销规则几乎每月变化。放在一起会导致高频率修改破坏稳定核心，拆出可独立演进。
• 加载性能显著下降：聚合包含 10+ 个实体，JOIN 过多，加载缓慢。

6.2 合并信号（满足任意一个应停止拆分）

• 总是一起加载和修改 ：例如 OrderItem 没有独立于 Order 存在的业务意义，且计算订单总额必须遍历所有订单项，永远和 Order 一起操作。
• 分布式事务复杂度远超收益：拆分后必须引入最终一致性和补偿，但这些代价已超出其带来的性能或解耦收益。
• 强不变量要求：数据必须同步一致，无法接受短暂延迟。如金融交易中的"资金扣减和账户记账"通常要求同事务。

6.3 决策流程

flowchart TD A[分析业务用例
绘制写入足迹] --> B{聚合内部分实体
有独立查询需求?} B -->|是| C[评估拆分] B -->|否| D{乐观锁冲突
集中在该部分?} D -->|是| C D -->|否| E{业务规则变更
频率相差大?} E -->|是| C E -->|否| F{加载性能
显著下降?} F -->|是| C F -->|否| G{总是一起加载修改
且强不变量?} G -->|是| H[保持不拆分] G -->|否| I{拆分后的分布式
事务代价可接受?} I -->|是| C I -->|否| H C --> J[设计新聚合边界
引入领域事件] H --> K[保持原聚合]

图说明：

1. 量化驱动：不以主观喜好决定，而是由写入足迹和锁冲突率等指标引导。
2. 成本评估：拆分不是免费的，必须评估最终一致性的开发成本和用户体验影响。
3. 迭代演化：聚合边界不应一开始就固定，应随业务发展持续重构。可从大聚合起步，在性能瓶颈显露时有依据地拆分。
4. 决策记录：拆分决策需记录理由和影响，便于后续回顾。

6.4 写入足迹分析实例（电商订单）

业务用例	涉及实体	不变量需求
用户下单	Order, OrderItem	订单总额=Σitem.price*quantity
卖家发货	Order.status, Shipment	状态必须为已支付且未发货
用户修改收货地址	Order.shippingAddress	无跨实体不变量
库存扣减	Inventory.quantity	availableQuantity >= 0
促销活动更新	Promotion.rule	与Order无直接不变量

分析可知，Inventory、Promotion 和 Order 的核心状态并无同步不变量，适合拆分为独立聚合。而 OrderItem 是 Order 的一部分，不可拆分。

---

7. 聚合不变量保护的设计模式

聚合的核心职责是保护其内部数据的业务不变量。实现要点：

• 方法封装业务逻辑 ：所有状态变更必须通过聚合根上的有业务含义的方法，例如 confirm()、cancel(reason)、deduct(quantity)。
• 方法内立即校验：不变量检查直接写在方法体最前面，失败则抛出异常，事务回滚。
• 杜绝 setter 暴露 ：将 JPA 的 setter 设为 private 或使用字段访问，防止外部绕过方法直接修改属性。

@Entity
public class Inventory {
    @Id private Long productId;
    private int availableQuantity;
    private int reservedQuantity;

    // JPA 要求，设为 protected 仅供框架使用
    protected Inventory() {}

    public void deduct(int quantity) {
        if (this.availableQuantity < quantity) {
            throw new InsufficientStockException("库存不足");
        }
        this.availableQuantity -= quantity;
        this.reservedQuantity += quantity;
    }
}

与第 7 篇防腐层中的校验职责区分：防腐层的校验（如输入格式、权限）属于应用层或适配层，聚合的不变量校验属于领域层核心。

---

8. 聚合与 CQRS/Event Sourcing 的协同

8.1 聚合是写模型的核心

在 CQRS 架构中，聚合只存在于写端，负责处理命令并产生领域事件。查询端完全不受聚合边界限制，可以灵活组合多个聚合的数据，形成满足前端展示的 DTO 或物化视图。

8.2 Event Sourcing 中的事件粒度

采用事件溯源时，聚合的每次状态变更都会产生一个或多个领域事件，事件流完全重放可重建聚合最新状态。聚合边界直接影响事件粒度：

• 大聚合 ：一次修改可能产生一个包含大量信息的"胖事件"（如 OrderUpdated），不易维护和重放。
• 小聚合 ：事件小而专注（如 OrderConfirmed、InventoryDeducted），各自独立，便于独立演进和重放。

本系列第 6 篇的 Axon Event Sourcing 实践已展示如何在聚合中应用 @CommandHandler 和 @EventSourcingHandler，聚合设计应与事件粒度一同考量。

---

9. 贯穿案例：电商订单系统聚合设计演进

9.1 初始大聚合形态

初版系统中，我们将 Order 聚合设计为包含一切：

@Entity
public class Order {
    @Id private Long orderId;
    @ManyToOne private User user;
    @OneToMany(cascade = ALL, orphanRemoval = true)
    private List<OrderItem> items;
    @ManyToOne private Payment payment;
    @OneToOne private Shipment shipment;
    // 各种状态和字段...
}

随着流量增长，页面加载一个订单列表需要连接订单、用户、支付、物流四张表，SQL 执行超过 1 秒。同时，修改物流信息（频繁操作）与订单状态变更冲突不断，乐观锁重试率高达 30%。

9.2 分析写入足迹，识别拆分点

通过分析写入足迹表，发现：

• 用户信息仅在下单时读取，后续永不修改，不应属于写模型。
• 支付、物流信息有独立的生命周期，频繁查询和更新，与订单核心状态无即时一致性要求。
• 库存扣减属于另一个限界上下文。

9.3 拆分：Product、User 独立，引入 ID 引用

首先将 User 和 Product 从 Order 聚合中移除，改为 ID 引用：

@Entity
public class Order {
    @Id private Long orderId;
    private Long userId;
    @ElementCollection
    private List<OrderItem> items; // 值对象，内聚在聚合内
    private String shippingAddress;
    private OrderStatus status;
    // ...
}

User 成为独立聚合，有自己的 Repository。查询时通过应用服务组合。

9.4 拆分 Payment 和 Shipment 为独立聚合，使用事件异步

支付成功后，发布 PaymentCompleted 事件，订单服务消费并修改订单状态为"已支付"；发货后发布 ShipmentDispatched 事件。这些操作都不再与订单本地事务绑定。

订单确认扣库存的最终一致性实现：

// Order 聚合
public void confirm() {
    if (this.status != PENDING) throw ...;
    this.status = CONFIRMED;
    registerEvent(new OrderConfirmed(this));
}

// 应用服务（事务边界）
@Transactional
public void confirmOrder(Long orderId) {
    Order order = orderRepository.findById(orderId);
    order.confirm();
}

库存服务监听事件：

@Transactional
@EventListener
public void handle(OrderConfirmed event) {
    for (OrderItem item : event.getItems()) {
        Inventory inv = inventoryRepo.findByProductId(item.getProductId());
        inv.deduct(item.getQuantity());
    }
}

若库存扣减失败，发布 InventoryDeductFailed，补偿服务取消订单：

@EventListener
public void on(InventoryDeductFailed event) {
    Order order = orderRepo.findById(event.getOrderId());
    order.cancel("库存不足");
    orderRepo.save(order);
}

9.5 拆分前后代码对比图

flowchart TB subgraph Before["大聚合（前）"] A["Order聚合"] --> B["User对象"] A --> C["Payment对象"] A --> D["Shipment对象"] A --> E["List"] end subgraph After["拆分后聚合（后）"] F["Order聚合
orderId, userId, items"] G["User聚合"] H["Payment聚合"] I["Shipment聚合"] J["领域事件"] F -.->|"userId引用"| G F -.->|"事件"| H F -.->|"事件"| I end classDef default fill:#f1f5f9,stroke:#334155,stroke-width:1.5px,color:#1e293b classDef after fill:#ede9fe,stroke:#8b5cf6,stroke-width:1.5px,color:#4c1d95 class F,G,H,I,J after

图说明：

1. 解耦程度：拆分后每个聚合独立数据库表，生命周期和并发控制隔离。
2. 通信方式：聚合间通过异步事件通信，不再共享事务。
3. 内聚性 ：OrderItem 留在 Order 内，因其与总额计算存在不变量。
4. 性能改善：锁冲突率下降到 2%，加载一个订单的 SQL 减少到 1～2 次 JOIN。

9.6 效果评估

经过拆分后：

• 订单页面加载时间从 1200ms 降至 80ms（利用读模型联表查询）。
• @Version 冲突率从 30% 降低至 2%。
• 库存扣减采用最终一致性，虽引入短暂延迟（<500ms），但通过 WebSocket 推送更新，用户体验可接受。
• 订单取消的补偿流程自动化，可靠率达 99.9%。

---

10. 与前后系列的衔接

• 第 2 篇（战术 DDD）：本文是聚合根基本实现的深度扩展，重点解决"聚合大小"这一结构性难题。
• 第 4 篇（事件驱动 CQRS）：聚合拆分后，跨聚合的最终一致性必然借助领域事件和 CQRS 架构，两者的设计相互制约。
• 第 6 篇（Axon Event Sourcing）：事件溯源中聚合的事件粒度由聚合边界决定，第 6 篇的 Axon 编程模型可直接承载本文的拆分设计。
• 第 7 篇（防腐层 ACL）：防腐层保护了领域层的纯净，本文聚合内部不变量保护与 ACL 的校验形成完整的防御体系。

---

11. 面试高频专题

11.1 核心面试题精解

Q1: 聚合设计的四项核心原则是什么？它们如何相互关联？

答：原则为：保护业务不变量、设计小聚合、通过唯一标识引用其他聚合、使用最终一致性更新其他聚合。

• 保护不变量：聚合根内封装校验，确保状态变更符合业务规则。
• 设计小聚合：控制聚合规模（1~5 实体），避免大事务和锁冲突。
• ID 引用：聚合间只持有 ID，避免对象引用造成的级联加载和跨聚合持久化。
• 最终一致性：跨聚合修改不再要求强一致，通过事件异步达成。

四者层层递进：小聚合迫使使用 ID 引用；ID 引用打破本地事务边界，必须依赖最终一致性；而所有这些手段均服务于更精准的不变量保护。

Q2: 为什么推荐小聚合？大聚合会带来哪些具体问题？

答 ：大聚合通常包含多个 @OneToMany 和 @ManyToOne 级联，导致：

• 加载性能差：N+1 查询、多表 JOIN 产生大量冗余数据。
• 并发冲突高：乐观锁版本号粒度过粗，无关修改相互阻塞。
• 事务范围大：长事务占用连接，增加死锁风险。
• 扩展性差：微服务拆分时，大聚合边界与物理服务边界不匹配。

通过实验数据：某个电商大聚合在压测下吞吐量仅 200 TPS，拆分后达到 800 TPS。

Q3: 聚合间为何只能通过 ID 引用，而不能持有对象引用？

答：对象引用带来以下问题：

• 级联陷阱：ORM 可能意外触发懒加载或级联更新，跨越事务边界。
• 边界模糊 ：开发者可直接 order.getUser().setName() 绕过 User 聚合的不变量。
• 耦合性：写操作容易在一个事务中同时修改多个聚合，导致将来微服务拆分困难。
• 测试复杂：单元测试需要构造完整的对象图。

ID 引用则强制通过 Repository 显式加载，界限清晰。

Q4: 如何保障"一次事务只修改一个聚合"？

答 ：应用服务方法上标注 @Transactional，内部仅调用单个聚合的 Repository 操作。跨聚合修改必须通过领域事件异步完成。例如：

@Transactional
public void confirmOrder(Long orderId) {
    Order order = orderRepository.findById(orderId);
    order.confirm();  // 内部注册OrderConfirmed事件
}

严禁在同一个 @Transactional 方法内调用 inventoryRepository.save()。编译器无法强制，需依靠代码审查和架构测试。

Q5: 跨聚合操作如何实现最终一致性？

答：通过"事件驱动 + 补偿"的 Saga 模式：

1. 聚合 A 完成本地事务并发布事件（如 OrderConfirmed）。
2. 消息中间件（或本地事件表）保证事件投递。
3. 聚合 B 消费事件，执行本地事务（如扣减库存）。
4. 若 B 失败，发布补偿事件（如 InventoryDeductFailed），A 执行回滚（订单取消）。
5. 整个流程需保证消费幂等，可通过事件 ID 去重表或 Redis 记录。

Q6: 如何判断聚合是否应该拆分？

答：采用"写入足迹分析 + 信号检查"：

• 绘制所有写用例涉及的实体，如果大部分修改仅涉及部分实体，且该部分实体有独立查询需求或修改频率差异大，则可拆分。
• 具体信号见第 6 节。实践中我会结合锁冲突率、慢查询日志和领域专家意见。

Q7: 什么情况下应该合并聚合？

答：当满足以下条件时考虑合并：

• 两个"候选聚合"总是一起加载和修改（如 Order 和 OrderItem）。
• 存在强实时一致性的不变量（如"订单总额 = 所有订单项金额之和"），无法接受短暂延迟。
• 拆分后引入的分布式事务成本（补偿逻辑、监控、运维）远超性能收益。
• 其中一个实体离开另一个无业务意义。

Q8: 聚合的不变量在哪里保护？

答 ：聚合根的方法内。所有状态变更必须通过具有业务语义的方法（如 confirm()），方法第一步进行校验，失败抛出异常。绝不允许暴露公开的 setStatus() 方法。这是 DDD 与"贫血模型"的核心区别。

Q9: 聚合设计与 CQRS 有什么关系？

答：聚合是写模型的边界，CQRS 将读写分离。聚合只负责处理命令，不关心查询；读模型可以自由组合多个聚合的数据，形成高效查询的 DTO 或物化视图。例如订单列表页面需要显示用户名、订单状态、物流信息，读侧直接 JOIN 表即可，无需受聚合边界限制。

Q10: 在电商系统中，订单确认和库存扣减如何既保证性能又不超卖？

答：采用"异步预占+最终确认"模式：

• 订单确认只更新订单状态，同步返回成功。
• 发布 OrderConfirmed 事件，库存服务异步扣减。
• 为防止超卖，库存服务使用乐观锁或 Redis 预减。若库存不足，发布补偿事件取消订单。
• 前端通过轮询或 WebSocket 获取最终结果，在秒杀场景下还可引入"库存预占"，进一步降低冲突。

11.2 系统设计实战：高并发秒杀系统的聚合设计与最终一致性

本节将聚合设计的理论应用到苛刻的秒杀场景，展示如何在"极致性能"和"不超卖"之间取得平衡，并提供完整的架构、流程、时序图和核心代码。

业务需求

• 商品限量秒杀，库存 1000 件，瞬时并发 10 万请求。
• 用户下单后需在 15 分钟内支付，否则释放库存。
• 系统不能超卖，但可接受极短暂的"下单未扣减"窗口。
• 订单与库存独立演进，后期可能拆分为微服务。

聚合设计

根据写入足迹，秒杀主要涉及两个核心写操作："创建订单"和"扣减库存"。二者不存在强实时不变量（只要最终不超卖），故拆分为两个独立聚合。

• SeckillOrder 聚合 ：orderId, userId, productId, quantity, status(CREATED/PAID/CANCELLED)。不变量：状态流转校验，订单必须在创建后 15 分钟内完成支付。
• Inventory 聚合 ：productId, availableQuantity, reservedQuantity。不变量：availableQuantity >= 0，扣减时确保不超卖。

聚合边界如图：

flowchart LR subgraph SeckillOrderAgg["SeckillOrder 聚合"] A["SeckillOrder 根"] --> B["OrderItem 值对象"] end subgraph InventoryAgg["Inventory 聚合"] C["Inventory 根"] end A -.->|"productId 引用"| C classDef seckill fill:#ede9fe,stroke:#8b5cf6,stroke-width:1.5px,color:#4c1d95 classDef inventory fill:#dbeafe,stroke:#2563eb,stroke-width:1.5px,color:#1e3a8a class A,B seckill class C inventory

图说明：

1. SeckillOrder 持有 productId，仅为引用，不加载 Inventory 对象。
2. 两个聚合有各自的 Repository 和数据库表。
3. 跨聚合操作依靠领域事件异步执行。
4. 订单项的秒杀价格等属于订单聚合内部值对象。

高并发架构与流程

我们引入 Redis 预减库存 + 消息队列削峰，架构如下：

flowchart TB U["用户"] -->|"下单请求"| GW["网关/负载均衡"] GW --> SS["秒杀服务"] SS -->|"1. Lua脚本预减库存"| REDIS["(Redis 库存缓存)"] SS -->|"2. 发送订单消息"| MQ["消息队列"] SS -->|"3. 立即返回订单号"| U MQ --> OS["订单服务（写）"] OS --> DB_ORDER["(订单数据库)"] MQ --> IS["库存服务（写）"] IS --> DB_INV["(库存数据库)"] IS -.->|"库存不足"| COMP["补偿服务"] COMP -->|"取消订单"| OS classDef userGw fill:#fef3c7,stroke:#d97706,stroke-width:1.5px,color:#92400e classDef service fill:#dbeafe,stroke:#2563eb,stroke-width:1.5px,color:#1e3a8a classDef middleware fill:#f1f5f9,stroke:#334155,stroke-width:1.5px,color:#1e293b classDef database fill:#e2e8f0,stroke:#475569,stroke-width:1.5px,color:#0f172a classDef compensation fill:#ede9fe,stroke:#8b5cf6,stroke-width:1.5px,color:#4c1d95 class U,GW userGw class SS,OS,IS service class REDIS,MQ middleware class DB_ORDER,DB_INV database class COMP compensation

图说明：

1. 极速响应：请求到达秒杀服务，先通过 Redis Lua 脚本原子性扣减库存（预减），成功则生成订单消息投递至 MQ，并立即返回"排队中"状态。用户无需等待实际落库。
2. 削峰填谷：MQ 将高峰期的订单消息暂存，订单服务和库存服务按自己能力消费，避免数据库过载。
3. 最终一致：订单服务和库存服务各自处理消息，若库存服务发现库存不足（Redis 超卖残余），则发布补偿事件取消订单。
4. 读写分离：订单查询、库存查询可走独立的读库或 Redis 缓存，完全不受聚合边界限制。

核心时序图

sequenceDiagram participant User participant SeckillService participant Redis participant MQ participant OrderService participant InventoryService participant DB User->>SeckillService: 发起秒杀请求 SeckillService->>Redis: EVAL lua_script 扣减库存 alt 库存不足 Redis-->>SeckillService: 返回 0 SeckillService-->>User: 秒杀失败 else 扣减成功 Redis-->>SeckillService: 返回 1 SeckillService->>MQ: 发送 OrderCreateCommand SeckillService-->>User: 返回订单号（排队中） end MQ-->>OrderService: 消费命令 OrderService->>DB: 创建 SeckillOrder 聚合 OrderService->>MQ: 发布 OrderCreated 事件 MQ-->>InventoryService: 消费 OrderCreated InventoryService->>DB: 扣减 Inventory 聚合 alt 扣减成功 InventoryService-->>MQ: 发布 InventoryDeducted else 扣减失败 InventoryService-->>MQ: 发布 InventoryDeductFailed MQ-->>OrderService: 消费失败事件 OrderService->>DB: 将订单标记为 CANCELLED end

图说明：

1. 原子预减：Redis Lua 脚本确保查库存与扣减的原子性，避免竞态。
2. 异步解耦：一旦消息发出去，秒杀服务即完成使命，后续流程由消费方异步推进。
3. 失败补偿：任何后期失败都会回滚订单状态，保证最终一致性。
4. 幂等消费 ：OrderService 和 InventoryService 必须基于 messageId 实现幂等，防止消息重复消费。

关键代码示例

Redis Lua 预减库存（原子操作）：

local key = KEYS[1]           -- 库存 key
local quantity = tonumber(ARGV[1])
local current = tonumber(redis.call('get', key) or "0")
if current >= quantity then
    redis.call('decrby', key, quantity)
    return 1
else
    return 0
end

SeckillOrder 聚合（不变量保护）：

@Entity
public class SeckillOrder {
    @Id private Long orderId;
    private Long userId;
    private Long productId;
    private int quantity;
    private OrderStatus status; // CREATED, PAID, CANCELLED
    private LocalDateTime createTime;

    public void pay() {
        if (this.status != OrderStatus.CREATED) {
            throw new OrderException("订单状态非法");
        }
        if (ChronoUnit.MINUTES.between(createTime, LocalDateTime.now()) > 15) {
            throw new OrderException("订单已超时");
        }
        this.status = OrderStatus.PAID;
    }

    public void cancel(String reason) {
        if (this.status == OrderStatus.CANCELLED) {
            return; // 幂等
        }
        this.status = OrderStatus.CANCELLED;
        registerEvent(new OrderCancelled(this.orderId, this.productId, this.quantity));
    }
}

Inventory 聚合：

@Entity
@Table(name = "inventory")
public class Inventory {
    @Id private Long productId;
    private int availableQuantity;
    private int reservedQuantity;

    public void deduct(int quantity) {
        if (this.availableQuantity < quantity) {
            throw new InsufficientStockException("库存不足");
        }
        this.availableQuantity -= quantity;
    }

    public void releaseReserved(int quantity) {
        this.reservedQuantity -= quantity;
        this.availableQuantity += quantity;
    }
}

应用服务（订单创建命令消费）：

@Transactional
public void handle(OrderCreateCommand cmd) {
    SeckillOrder order = new SeckillOrder(cmd.getOrderId(), cmd.getUserId(),
                                          cmd.getProductId(), cmd.getQuantity());
    orderRepository.save(order);
    // 发布 OrderCreated 领域事件，由框架在事务提交后投递
}

补偿流程 ：当 InventoryDeductFailed 触发时，订单服务回滚订单：

@Transactional
@EventListener
public void on(InventoryDeductFailed event) {
    SeckillOrder order = orderRepository.findById(event.getOrderId());
    order.cancel("库存扣减失败");
}

一致性与性能权衡分析

• 强一致方案（XA 分布式事务）：性能极差，锁范围大，不适合秒杀。
• 本方案（最终一致）：通过 Redis 预减将大部分无效请求挡在外部，数据库实际流量很小。短暂不一致窗口由补偿逻辑处理，业务上可接受。
• 监控与告警：补偿事件频率、订单超时未支付量、Redis 与 DB 库存差异等需要实时监控，避免出现意外超卖。

通过该设计，秒杀系统能够支撑 10 万 QPS 的瞬时流量，而数据库 TPS 仅需数百，库存不超卖保证率达 99.99%。

---

总结

聚合设计是 DDD 战术实现中最具艺术性的环节：它要求开发者同时兼顾业务语义的准确性和技术执行的性能。小聚合优先，通过 ID 引用和最终一致性打破同步事务的限制；拆分与合并决策框架提供了科学的分析路径；不变量保护确保了模型的完整性。以电商订单系统为镜，我们看到从大聚合到合理拆分，性能与可维护性获得质的飞跃。而在秒杀等极端场景，聚合设计与高性能架构（Redis、MQ）的有机结合，进一步验证了这些原则的生命力。希望本文能为你手上的项目提供可落地的"尺子"，量出最适合的聚合边界。

---

延伸阅读

• Vaughn Vernon，《实现领域驱动设计》第 10 章：聚合设计。
• Martin Fowler，"Aggregate"模式相关文章。
• Axon Framework 官方文档，Saga 与事件处理。
• 本系列第 2 篇：战术 DDD 与 Spring 实现。
• 本系列第 6 篇：Axon Event Sourcing 实践。

---

附：Demo 代码仓库

（注：此处附上代码片段清单，完整代码可访问示例仓库。）

• BigOrderEntity.java：初始大聚合反模式示例。
• Order.java：拆分后的聚合根，含事件注册。
• Inventory.java：库存聚合，含不变量保护。
• OrderApplicationService.java：事务边界与事件发布。
• InventoryEventHandler.java：事件消费与补偿逻辑。
• SeckillOrder.java：秒杀订单聚合。
• RedisLuaScript.lua：原子预减库存脚本。