1. 聚合与聚合根先搞清楚它们到底解决什么问题很多人在刚接触 DDDDomain-Driven Design领域驱动设计时最头疼的往往不是那些晦涩的战术模式概念而是“聚合”Aggregate和“聚合根”Aggregate Root到底怎么落地。你在项目里搜索资料能看到一堆人说“聚合是领域模型的边界”“聚合根是唯一对外访问的入口”但一到实际设计面对一个真实的业务场景还是不知道从哪下手——订单要不要拆成多个聚合用户和订单是不是一个聚合评论算不算商品的子实体这篇文章我用一个接近真实业务的订单域例子完整走一遍聚合与聚合根的设计过程把我踩过的坑、走过的弯路、反复调整后的判断标准一并写清楚。你读完至少能明白三件事聚合的边界怎么划、聚合根的状态怎么管理、聚合服务在哪个层面真正发挥作用。先说结论聚合设计没有标准答案但有可复用的推导路径。它本质上是在回答三个问题——哪些对象必须保证事务一致性哪些对象允许最终一致对外的操作入口应该收敛在哪1.1 没有聚合的年代问题出在哪要理解聚合的价值先回到“没有聚合”的世界。假设我们在做一个订单系统早期版本非常简单数据库表也不多业务逻辑直接写在Service里public void submitOrder(String orderId) { Order order orderRepository.findById(orderId); // 校验余额 accountService.checkBalance(order.getUserId(), order.getTotalAmount()); // 扣减库存 stockService.deductStock(order.getItems()); // 更新订单状态 order.setStatus(OrderStatus.SUBMITTED); orderRepository.save(order); }看起来一切正常但问题藏在细节里任何一个操作都可能绕过订单状态检查直接修改明细行业务规则散落在各个服务里每个调用方都自己实现一遍“金额校验”一个用户同时提交两个订单库存被扣了两次没有地方保证整体一致性。当时项目里最典型的一个场景是这样的订单主表、订单明细表、支付流水表、配送信息表各自都有独立的Repository和Service。下单时先往订单主表插一条再往明细表插几条再生成一条支付记录再新建一条配送单。每个步骤都有事务但跨表操作就是没法形成一个整体。后来随着需求多起来“该不该同一事务”“哪些数据必须一起变更”就永远在争论中。聚合这个概念解决的就是这件事把业务上必须同时满足一致性的对象圈在一起形成一个“一致性边界”边界内部的所有变更都必须通过聚合根进行边界以内的所有数据变更对外表现为一个原子操作。换句话说聚合不是数据建模而是事务边界建模、一致性建模。1.2 聚合、聚合根、实体、值对象先分清这几个概念很多人把聚合和聚合根混为一谈一言不合就说“这里设计一个聚合根”其实聚合根只是聚合这个集合里的“队长”一个聚合一定要有且仅有一个聚合根。为了更直观我用一个生活化类比来讲。想象你在一家快餐店点了一份汉堡套餐汉堡、薯条、可乐。套餐是一个聚合汉堡是这个套餐的聚合根因为整个套餐的订单、价格、套餐编号都落在汉堡身上——你要是单点可乐它不属于这个套餐聚合你要是点了两份薯条那是另外一份套餐的事。套餐内任何变动换大份薯条、改可乐为雪碧都只能通过汉堡收银员对着套餐编号操作来改不能直接拿一包薯条去前台说“把我的薯条换掉”因为前台并不知道这包薯条属于哪个套餐。套用到领域模型里实体Entity有唯一标识、有生命周期、状态可变的领域对象。订单、用户、商品都是实体。值对象Value Object没有唯一标识、不可变、靠属性值本身来识别。金额、地址、电话号码都是典型的值对象。聚合Aggregate一组相关对象的集合是数据变更的一致性边界。聚合根Aggregate Root聚合中唯一允许被外部直接引用的对象也是聚合内其他对象的“访问入口”。外部对象想操作聚合内部的任何数据都必须通过聚合根转发。2. 聚合根设计的关键原则不要过度设计也不要形同虚设从实际落地的经验来看聚合根设计最容易走两个极端一种是什么都往一个聚合里塞结果一个订单聚合包含了用户、商品、库存、优惠券聚合根重得跑不动另一种是每个实体都做成一个聚合根订单、订单项、支付、配送各自为政结果聚合名存实亡一致性边界完全消失。所以我想先讲原则再讲案例。原则是“道”案例是“术”。光看案例照猫画虎换个业务场景你就不会用了。2.1 聚合根的本职管理不变量而不是管理数据聚合根的核心职责是维护聚合内部所有对象的“不变量”Invariant。什么叫不变量就是业务上无论如何都不能被打破的规则。订单聚合里有一个很典型的不变量订单总金额必须等于所有订单项金额之和。另一个典型的不变量已提交订单不能再修改明细。也就是说聚合根不是“对象的集合”而是“规则的守护者”。每次外部发起一个操作比如“添加订单项”“修改数量”“取消订单”都必须经过聚合根聚合根在执行操作前检查规则执行操作后保证聚合内部状态依然是合法的。这一点特别容易被误解成“聚合根就是对象的门面”或者“聚合根就是为ORM准备的根实体”。如果你把聚合根设计成一个几乎没有任何业务行为的“数据容器”那聚合根就形同虚设了。它的存在感应该体现在行为上而不是体现在“你是根所以你最大”上。比如下面这种写法就是典型的“形同虚设”public class Order { private String id; private String userId; private BigDecimal totalAmount; private ListOrderItem items; public BigDecimal getTotalAmount() { return totalAmount; } public void setTotalAmount(BigDecimal totalAmount) { this.totalAmount totalAmount; } public ListOrderItem getItems() { return items; } }Order 没有任何保护数据的能力外面想怎么改就怎么改。这种代码换个类名放在 Service 里调用跟用 DataSet 操作数据表没有任何本质区别。2.2 “一致性边界”划多大取决于业务而不是数据关联之前有个同事问我“用户和订单关联这么紧密要不要把用户设计成订单聚合里的实体”我说你这个问题一出来就说明你把聚合和“外键关系”搞混了。两个人如果有外键关联就必须在一个聚合里那整个系统都是聚合了。聚合边界划分唯一的标准是事务一致性如果两个对象在业务上必须同时变化、同时满足规则那它们就在一个聚合里。如果允许短暂的不一致、可以通过后续流程补偿那它们就分属不同的聚合。这个判断标准看起来清晰但实际用的时候容易犹豫。通常有两个典型的判断抓手第一个抓手看业务操作是不是原子的。比如“创建订单”这个操作是不是一定需要同时校验商品库存如果库存校验失败订单能不能先创建成功、稍后异步处理如果能那商品和订单就不在一个聚合。如果不能那它们需要一起变化可能要考虑放在一起或者通过其他机制保证一致性。第二个抓手看聚合根之间用ID引用还是用对象引用。聚合与聚合之间永远只能通过聚合根ID相互引用。如果一个聚合内的实体“持有”另一个对象并直接调用它的方法去修改状态那它就已经把对方拉进自己的聚合了。实际项目中聚合之间只能使用ID引用这是硬性规定。2.3 聚合设计的四条实操准则基于我自己的实践我总结了四条可以日常对照的准则。准则一聚合根要有全局唯一的标识。这个标识在聚合之外是唯一的引用方式在聚合之内是实体身份的统一入口。哪怕订单下面有不同的订单项每个订单项在数据库里也有自己的主键但在领域模型里订单项的身份是“属于OrderId为xxx的订单的第几项”它不是全局独立对象。准则二聚合内部的实体可以与其他内部实体双向访问但聚合外部只能访问聚合根。这是防止聚合边界“漏风”的关键。如果允许外部直接拿到聚合内部的实体对象并修改状态那聚合的保护就名存实亡了。这也是我在下面案例里反复强调的一点仓储接口只暴露聚合根不暴露内部实体。准则三聚合内的对象之间通过“整体加载、整体保存”来保证一致性。加载订单时订单及其所有订单项作为一个整体被加载保存时订单及其订单项作为一个整体被保存。否则就会出现“订单保存了、明细没保存”的中间状态。准则四聚合不要设计得太大也不要太小。太大则事务时间过长、并发冲突严重、加载效率低太小则一致性边界破碎、业务规则无处安放。理想的聚合大小是“刚好能维护一组不变量所涉及的对象集合”。3. 从零开始设计一个订单聚合一步步的实操推导下面我把前面这些原则串起来用一个订单案例做完整的实操推导。很多人上来就问“订单聚合怎么定义”我会反问一句“你订单的业务规则是什么”业务规则不同聚合的设计就不同。我这里用一个小型电商订单场景尽量拆得细致一点。3.1 业务场景设定假设我们做的是一个B2C商城核心流程是用户浏览商品、加入购物车、提交订单、支付、发货。刚开始项目很小但我们希望从一开始就用DDD的方式组织代码避免后续业务复杂化之后重构成本过高。我们需要重点关注的业务事实一个订单包含一个或多个订单项每个订单项对应一个商品ID、数量、购买时单价。订单提交后订单项不允许随意增删改。订单取消时所有订单项同时取消订单总金额归零。一个订单只有一条配送信息。订单创建时需要校验商品是否可售、数量是否足够但这些校验发生在“提交订单”阶段而不是“保存订单草稿”阶段。支付信息、配送轨迹、售后记录会随着流程逐步产生但它们并不是订单创建时就必须一致包含的数据。我在实际项目中碰到过一种错误做法把商品快照、库存、支付、物流全部塞进订单聚合结果每次加载订单都要关联十几张表并发冲突极其严重。这里我们先做正确的事从一致性角度分析哪些对象必须属于订单聚合。3.2 找出聚合边界哪些对象在同一个“一致性王国”第一步画出业务场景中的关键对象订单Order订单项OrderItem配送信息DeliveryInfo支付记录Payment物流轨迹LogisticsTrack商品Product库存Inventory第二步逐个分析一致性关系。订单和订单项强一致。订单金额、订单状态都依赖于订单项订单项一变订单的总额就变。订单取消时订单项必须一起取消。所以订单项必须是订单聚合内的实体。订单和配送信息提交订单时配送信息是必须填写的内容之一配送地址更新会直接影响订单的有效性。在某个业务场景里地址纠纷、配送时效都与订单本身绑定。配送信息没有独立的生命周期脱离订单谈配送信息没有意义。所以配送信息可以作为订单聚合内的一个实体也可以设计成值对象。这里我倾向于把它设计成一个值对象后面会细说。订单和支付记录支付是订单状态的推进器。但支付记录拥有自己的生命周期它可能支付成功、支付失败、退款、部分退款。支付失败时订单本身依然存在只是状态停留在“待支付”。支付成功后订单状态会更新为“已支付”——这其实是通过两个聚合之间的协作完成的而不是把支付记录硬塞进订单聚合。所以支付记录应该是一个独立的聚合根。订单和物流轨迹物流轨迹是物流系统写入的它有自己的来源第三方物流接口和生命周期订单只是读取它来展示状态。如果放在一个聚合里每次物流更新都要加载整个订单代价太大。所以物流轨迹是独立的聚合。订单和商品、库存提交订单时需要检查商品是否可售、数量是否足够但商品信息和库存快照在订单创建之后就不再与订单发生事务性变化。订单项里保存的应该是“商品ID 购买时名称 购买时单价”这样一个商品快照值对象而商品本身和库存则属于商品聚合、库存聚合。订单创建完成后商品变价、库存波动都不应该影响订单聚合的一致性。最终我们确定的聚合划分为订单聚合聚合根是Order包含OrderItem实体、DeliveryInfo值对象、商品快照值对象。支付聚合聚合根是Payment包含支付流水等信息。商品聚合聚合根是Product包含商品基本信息。库存聚合聚合根是Inventory包含库存数量等。物流聚合聚合根是LogisticsTrack包含物流轨迹信息。3.3 定义聚合根和内部对象现在我们来写订单聚合的领域模型。我会用Java代码来演示因为它在DDD落地案例中出现得比较多但思路是语言无关的。先定义订单聚合根public class Order { private OrderId id; private UserId userId; private OrderStatus status; private Money totalAmount; private ListOrderItem items; private DeliveryInfo deliveryInfo; private LocalDateTime createdAt; private LocalDateTime submittedAt; // 构造函数创建订单的入口 public Order(OrderId id, UserId userId, DeliveryInfo deliveryInfo) { this.id id; this.userId userId; this.status OrderStatus.PENDING; this.deliveryInfo deliveryInfo; this.items new ArrayList(); this.totalAmount Money.zero(); this.createdAt LocalDateTime.now(); } // 添加订单项维护“总额 各项之和”的不变量 public void addItem(ProductSnapshot product, int quantity, Money unitPrice) { if (this.status ! OrderStatus.PENDING) { throw new IllegalStateException(只有待确认的订单才能添加订单项); } if (quantity 0) { throw new IllegalArgumentException(数量必须为正数); } // 检查商品是否已存在若存在则合并数量 for (OrderItem item : items) { if (item.getProductId().equals(product.getProductId())) { item.increaseQuantity(quantity); this.totalAmount this.totalAmount.add(unitPrice.multiply(quantity)); return; } } this.items.add(new OrderItem(product, quantity, unitPrice)); this.totalAmount this.totalAmount.add(unitPrice.multiply(quantity)); } // 提交订单校验状态、校验明细非空 public void submit() { if (this.status ! OrderStatus.PENDING) { throw new IllegalStateException(订单已提交不能重复提交); } if (this.items.isEmpty()) { throw new IllegalStateException(订单不能没有明细); } this.status OrderStatus.SUBMITTED; this.submittedAt LocalDateTime.now(); } // 取消订单只有待提交/待支付状态的订单可以取消 public void cancel(String reason) { if (this.status OrderStatus.PENDING || this.status OrderStatus.SUBMITTED || this.status OrderStatus.PAID) { this.status OrderStatus.CANCELED; this.totalAmount Money.zero(); } else { throw new IllegalStateException(当前状态不能取消订单); } } // 确认支付完成由支付回调触发 public void markPaid() { if (this.status ! OrderStatus.SUBMITTED) { throw new IllegalStateException(只有已提交的订单才能被标记为已支付); } this.status OrderStatus.PAID; } public OrderId getId() { return id; } public OrderStatus getStatus() { return status; } public Money getTotalAmount() { return totalAmount; } public ListOrderItem getItems() { return Collections.unmodifiableList(items); } }这里有几个细节我特别说一下。第一Order的构造函数只传入必要参数ID、用户ID、配送信息商品项通过addItem方法逐步添加而不是在构造函数里传一个List。这样便于在添加过程中维护不变量。第二totalAmount不是由DB算出来的而是在每次addItem、cancel时同步更新保证“总和一致”的不变量始终由聚合根守护。第三所有状态变更方法addItem、submit、cancel、markPaid都会先检查当前状态。外部代码无法绕过这些方法来修改订单。再定义OrderItem实体。它不需要对外暴露Repository因为它的生命周期完全由Order管理public class OrderItem { private ProductSnapshot productSnapshot; private int quantity; private Money unitPrice; public OrderItem(ProductSnapshot productSnapshot, int quantity, Money unitPrice) { this.productSnapshot productSnapshot; this.quantity quantity; this.unitPrice unitPrice; } public ProductId getProductId() { return productSnapshot.getProductId(); } public void increaseQuantity(int quantity) { this.quantity quantity; } public Money getSubTotal() { return unitPrice.multiply(quantity); } public ProductSnapshot getProductSnapshot() { return productSnapshot; } }注意OrderItem内部保存的是ProductSnapshot而不是Product对象。ProductSnapshot是商品信息的不可变快照捕获了商品在加入订单那一刻的名称、图片、价格等信息。这样做的原因很实际下单后商品改价、改名、下架都不应该影响历史订单。接下来是DeliveryInfo值对象public class DeliveryInfo { private final String receiverName; private final String phone; private final String province; private final String city; private final String detailAddress; public DeliveryInfo(String receiverName, String phone, String province, String city, String detailAddress) { this.receiverName receiverName; this.phone phone; this.province province; this.city city; this.detailAddress detailAddress; } // getter 方法省略 }DeliveryInfo设计成值对象非常合适它没有唯一标识两个配送信息只要各个属性相同就是同一条它不需要单独存储订单删除它就没有存在的意义它在订单生命周期内是整体替换而不是修改局部。最后是ProductSnapshot值对象public class ProductSnapshot { private final ProductId productId; private final String productName; private final String imageUrl; public ProductSnapshot(ProductId productId, String productName, String imageUrl) { this.productId productId; this.productName productName; this.imageUrl imageUrl; } // getter 方法省略 }3.4 为什么配送信息是值对象订单项是实体设计完内部对象很多人会问配送信息也是“有属性、有变化”的对象为什么它不是实体订单项也是“有数量、有单价”的对象为什么它是实体关键区别在于实体有“身份”和“生命周期”值对象只有“属性值”。订单项在订单内是唯一的一份订单里同一商品可以合并也可以拆分订单项可以增加数量、可以修改数量它有自己在这个聚合内的语义位置。更重要的是业务上可能针对单个订单项发起售后、退款、评价这些操作都需要能够指到具体的某一项。所以订单项必须有身份哪怕只是一个局部身份productId orderId。配送信息没有这种需求。它不参与退款、不参与售后、没有独立状态变化。地址变了整体替换成一个新的DeliveryInfo就是了。给它一个ID、建一张表、引入一堆getter/setter都是纯粹的增加复杂度。这就是值对象的意义让没有身份的东西保持轻量别给它硬造出身份。3.5 订单聚合的仓储接口怎么设计聚合内部的对象不能单独暴露仓储接口这是DDD落地过程中一个非常容易破功的点。我见过不少团队嘴上说“订单是一个聚合”结果代码里照着写了OrderRepository、OrderItemRepository两个仓储接口。这等于把聚合的内部对象暴露给了外部世界。正确的做法是只暴露一个OrderRepository操作粒度就是整个聚合public interface OrderRepository { Order findById(OrderId orderId); void save(Order order); void delete(Order order); }仓储的save方法签名接收整个Order聚合根至于内部怎么拆、怎么保存明细、怎么处理DeliveryInfo那是基础设施层的事领域层不需要关心。这里面还有一个实战经验拿到订单聚合根之后尽量不要直接从仓储返回的“实体”上去调用状态变更方法而应该通过应用服务组装用例再调用一个明确的方法。比如“取消订单”这个用例应用服务做的事情是通过OrderRepository.findById加载订单聚合根。调用order.cancel(reason)。通过OrderRepository.save(order)保存。应用服务既不做业务判断也不修改订单状态。业务判断、状态修改、不变量维护都在聚合根内部完成。这样代码的可测试性会变得非常好不用启动数据库直接new一个Order调用addItem、submit、cancel断言状态即可。4. 聚合服务层应用服务、领域服务、仓储的职责怎么分讲完聚合根再来讲“聚合服务”这个容易被模糊化的概念。很多时候大家说“DDD聚合服务”其实指的是围绕聚合根的一组服务。这组服务分两个层次应用服务和领域服务。如果没分清楚代码很快就会退化成“贫血模型 Transaction Script”的风格。4.1 应用服务编排用例不装业务规则应用服务Application Service是面向用户的用例入口。它的职责是协调聚合根、领域服务、外部接口来完成一个完整的业务操作。它负责事务边界、权限校验、事件发布但它不应该包含“业务规则”。以“提交订单”为例应用服务的代码是这样Service public class OrderApplicationService { private final OrderRepository orderRepository; private final ProductService productService; private final InventoryService inventoryService; private final PaymentService paymentService; public void submitOrder(SubmitOrderCommand command) { // 1. 创建订单聚合根此处简化实际可能需要先创建草稿 OrderId orderId orderRepository.nextId(); Order order new Order(orderId, command.getUserId(), command.getDeliveryInfo()); // 2. 往订单聚合里添加商品项商品信息从商品聚合获取快照 for (SubmitOrderItem item : command.getItems()) { ProductSnapshot snapshot productService.getSnapshot(item.getProductId()); order.addItem(snapshot, item.getQuantity(), item.getUnitPrice()); } // 3. 提交订单 order.submit(); // 4. 校验并扣减库存这里通过领域服务协调库存聚合属于最终一致或强一致取决于业务 inventoryService.deductStock(order); // 5. 保存订单聚合 orderRepository.save(order); // 6. 发布订单提交事件 eventPublisher.publish(new OrderSubmittedEvent(order.getId(), order.getUserId(), order.getTotalAmount())); } }这里要注意库存扣减的部分我特意没有放进订单聚合根内部。因为库存属于独立的库存聚合订单聚合和库存聚合之间的一致性我们在这里通过应用服务编排来达到事务层面的协同在真实项目中还会考虑分布式事务、本地消息表等方案。如果为了“省事”把库存聚合拉进订单聚合里订单聚合就会越来越大最终谁都扛不住。4.2 领域服务处理跨聚合的协作逻辑但不承载状态领域服务Domain Service和聚合根之间最常见的混淆点是什么时候该用领域服务什么时候该把逻辑放进聚合根。我的经验是如果一个业务操作只涉及一个聚合这个逻辑应该尽量塞进聚合根的领域方法里。如果一个业务操作需要协调多个聚合或者依赖外部系统的返回值才能做出决策那么这个逻辑适合放在领域服务里。举个例子。订单支付成功后的处理需要同时更新支付聚合和订单聚合。支付聚合负责记录支付流水并确定支付状态订单聚合负责在收到支付成功后变更订单状态。这两个聚合之间没有“组合”关系它们相互独立但需要协作完成“订单支付成功”这个业务事实。这时就可以写一个PayOrderDomainServiceService public class PayOrderDomainService { private final PaymentRepository paymentRepository; private final OrderRepository orderRepository; public void markPaid(OrderId orderId, PaymentId paymentId) { Payment payment paymentRepository.findById(paymentId); Order order orderRepository.findById(orderId); payment.markSuccess(); // 支付聚合根的状态变更 order.markPaid(); // 订单聚合根的状态变更 paymentRepository.save(payment); orderRepository.save(order); } }你会发现领域服务并不执行业务规则业务规则依然在各自聚合根内部。领域服务只是“把不同聚合根的结果按用例需要拼装起来”。如果把markPaid这个逻辑放在订单聚合根里那订单聚合根就需要注入PaymentRepository去操作支付聚合两个聚合就打破了边界隔离。4.3 服务层调用的一个实战例子取消订单的完整流程为了让你把应用服务和领域服务的分工看得更清楚我再举一个“取消订单”的例子。取消订单这个操作表面上看起来很简单把订单状态置为已取消。但真正上线后你会发现后面还连着一堆事如果订单已支付需要退款如果库存已经扣减需要回补库存如果已经发货需要拦截配送需要记录取消原因需要通知用户。这些操作如果全部写在订单聚合根的cancel方法里聚合根就会依赖一大堆外部服务。这是典型的“大杂烩”反模式。正确的设计是订单聚合根提供cancel方法只负责维护订单状态和订单内明细的取消不变量。应用服务OrderApplicationService.cancelOrder()负责编排整个用例查询订单判断状态调用cancel方法保存订单调用退款接口调用库存回补接口发布OrderCanceledEvent。如果有“是否允许取消”这样的跨聚合规则比如“已发货订单不允许客户自主取消”可以由领域服务OrderCancellationPolicy执行规则校验然后决定是否执行取消。这样分离之后每个方法都短小清晰也容易写单元测试。聚合根方法只测试状态变化应用服务方法用Mock的外部依赖测试编排领域服务单独测试规则逻辑。这是我实践中觉得性价比最高的结构。5. 订单聚合之外的设计扩展支付、商品、库存怎么独立演化前面的大篇幅都在讲订单聚合因为它是整个业务的核心。但聚合设计从来不是“设计好一个就完了”的事还要考虑它如何与其他聚合协同。这一节我把支付、商品、库存这几个聚合的要点也梳理一下因为它们和订单聚合的交互方式决定了系统的整体架构。5.1 支付聚合独立生命周期下的状态机支付聚合和订单聚合最大的区别在于支付有自己独立的状态机待支付、支付中、已支付、已退款、部分退款并且它的状态变化通常是从支付渠道回调驱动的。这意味着支付聚合根需要处理渠道回调、对账单、退款申请等自己的业务事件。如果把支付聚合塞进订单聚合每次支付回调都要加载订单及其所有明细——订单大时性能极差而且支付回调的频率很高订单表会被频繁查询容易产生热点行锁竞争。所以支付聚合单独设计聚合根是Payment类内部可以包含PaymentTransaction支付流水实体、RefundRecord退款记录实体。它对外暴露如下核心方法pay(): 创建支付单对接渠道下单。handleCallback(channelResult): 处理支付渠道回调。requestRefund(...): 发起退款申请。confirmRefund(...): 确认退款完成。订单聚合与支付聚合之间的通信方式是什么不是方法调用而是事件。支付成功事件PaymentSucceededEvent发出后由应用服务监听并调用订单聚合根的markPaid方法。这样的话未来如果出现新的支付渠道只需要扩展支付聚合订单聚合完全不受影响。5.2 商品聚合快照模式保住订单的“历史记忆”商品聚合看起来简单就是商品的增删改查但它有一个容易踩的坑订单项引用了商品ID之后商品改名了历史订单显示的名称却跟着变了。这在电商系统里是绝对不能接受的因为财务、售后、对账都依赖订单快照。解决方式就是前面提到的ProductSnapshot值对象。在用户提交订单时应用服务从商品聚合取回当前商品信息构造不可变快照传给订单聚合根。订单聚合保存的快照与商品聚合后续的任何变更都不再相关。有同事问过我如果商品后续新增了“规格”“重量”“批次”等属性快照是不是也要跟着加字段是的但你的快照只需要保留对订单业务有意义的字段不用面面俱到。一个原则快照保留的是“订单履约时用户看到和确认的信息”而非商品的全部属性。5.3 库存聚合强一致还是最终一致要说得清清楚楚订单创建时扣库存这是一个经典的分布式事务难题。先把话放在这里千万不要为了“显示你懂DDD”就把库存塞进订单聚合。库存的高并发特性、强一致扣减需求、催补单、超卖控制都是一套独立而复杂的业务逻辑。库存聚合的设计通常有两种选择。第一种强一致模式。在提交订单时通过应用服务在同一个本地事务里先锁定库存再创建订单。如果库存扣减失败整个事务回滚订单不存在。这种方式实现简单但会把订单创建的并发吞吐压死在库存行锁上秒杀活动场景基本扛不住。第二种最终一致模式。订单创建成功先落库状态为“待扣库存”通过领域事件发出“订单已创建”消息库存服务订阅事件异步扣减。扣减成功则订单继续流转扣减失败则进入补偿流程订单被自动取消并通知用户。我个人在实际项目中的体会是绝大多业务场景第二种更健康。它换来的是更高的吞吐与更清晰的边界代价是要额外处理补偿逻辑。选择哪种方式一定要在产品需求层面就把一致性问题说清楚而不是在代码层面临时拍脑袋。6. 常见问题与排查思路聚合设计最容易翻车的五个场景写到这核心的设计过程已经讲完了。最后一节我花些篇幅整理聚合设计落地时最容易出问题、也最常被问到的一些点。这些都是我在实际项目里碰到过、或者给别的团队做代码评审时反复看到的。6.1 订单加载性能太差是不是聚合设计错了有人反馈订单列表每次都要加载所有明细明细多了速度就慢。这种情况需要区分列表页和详情页的加载粒度是不同的。订单列表可能只需要聚合根上的核心字段订单号、状态、金额、下单时间不需要加载明细。这时可以在仓储上提供轻量查询方法比如findSummaryByUserId返回只包含聚合根核心属性的投影对象而不是完整的Order聚合根。DDD并不要求所有查询都走聚合根。CQRS命令查询职责分离在这里就派上用场了写模型Command使用聚合根读模型Query可以绕过聚合根直接查自己需要的字段。所以碰到这种问题先别急着改聚合边界先看看查询方式是不是绕过了聚合根。6.2 订单和支付到底怎么同步双重聚合更新的问题在这种跨聚合协作中最头疼的就是“两个聚合在同一个事务里各更新一次”。数据库层面你用本地事务包住两次save当然能保证一致但两个聚合之间没有任何领域层面的原子性随着业务发展支付服务和订单服务迟早会拆成两个进程这份“虚假的安全感”会立刻消失。我的习惯做法是引入领域事件 本地事件表。订单聚合根内部不再直接调用支付服务或订单服务而是在状态变更处触发领域事件。应用服务负责把事件写入本地事件表由后台任务或者消息中间件把事件发布出去下游服务订阅事件后完成自己的聚合更新。这样聚合根的方法依然是纯粹的领域逻辑跨聚合的一致性由事件机制来保障。6.3 聚合根之间能不能相互引用对象一个非常典型的问题Order里能不能直接持有一个User对象引用我的答案很明确不要。Order需要用户ID但不需要持有整个用户对象。如果你在Order里直接引用UserUser就变成了订单聚合的一部分用户的任何修改比如改了手机号都必须和订单一起保存否则数据就可能不一致。更糟糕的是加载订单时必须同时加载用户订单模块就和用户模块产生了强耦合。正确的做法是Order聚合根内部保存一个UserId值对象需要展示用户信息时由应用服务通过UserId去用户上下文中查询。同样的规则适用于所有外部对象商品ID、库存ID、支付ID。这条规则我用下来它能一票否决掉最多的问题设计。6.4 聚合根下的实体能不能有自己的仓储前面提到过这里再强调一次不能。如果OrderItem有自己的Repository那它就拥有了绕过聚合根独立存在的能力。哪怕你只是“偶尔”用它查一下数据也会让后续的写操作变得不可控——因为你会忍不住想要“偶尔”改一下。我曾在一个项目里看到类似的设计订单项有独立的Repository商品评论功能直接引用订单项ID来关联“购买后评价”。表面看没问题但等到做售后处理时那才是噩梦的开始状态变了、订单项缺席、金额对不上排查了整整两天。最后把这块逻辑收回到订单聚合根在聚合根上暴露一个afterSale()方法问题迎刃而解。6.5 聚合根越来越大要不要拆订单聚合最初设计得还算合理但随着需求增加聚合根慢慢膨胀新增了定制需求、附加服务、礼品卡绑定……十几个方法堆在那里文件越来越大测试也越来越难写。判断要不要拆核心看“新加的功能是否仍然依赖同一个业务不变量”。如果新的功能只是让订单内部多几个对象那不拆如果新的功能引入了新的生命周期——比如第三方代付的支付单它的生命周期不仅独立于订单还要支持催付、关单、对账那它就应该是一个新的聚合。总之一句话聚合的拆分不是看字段多不多而是看生命周期归不属于同一个。场景判断方向结论订单加载慢是否总是加载完整聚合引入CQRS轻量查询跨聚合双写是否有本地事务假安全引入事件机制解耦聚合间引对象是否有对象引用而非ID引用改成ID引用内部实体有仓储是否绕过聚合根操作数据收敛到聚合根聚合根膨胀新需求是否共享同一生命周期按生命周期拆分新聚合7. 我的实操体会聚合设计是一场“持续演进”的迭代过程最后说一点个人在实际操作中的体会。前面讲了那么多原则和方法但聚合设计从来不是一次建模就能到位的。新需求来了聚合边界会发现新的问题系统规模大了原来合适的边界也可能需要调整。DDD的好处在于它给了你一套判断“边界是否合适”的思考工具而不是一套一成不变的模板。我刚接触DDD的时候犯过很多错误设计过无比巨大的订单聚合把所有关联对象都塞进去被性能问题教训过后来又把聚合拆得极其碎每个实体都恨不得独立成聚合根被一致性问题折腾过。现在回头看边界感只有通过真实项目不断打磨才能形成——多问自己“这个操作失不失败、业务允不允许短暂不一致”比背一百种聚合设计范例管用。我的建议是从一个小模块开始尝试不需要一上来就全系统DDD化。比如在一个新项目里把订单域按聚合模型落地其他模块暂时保持CRUD风格。等跑通了几轮需求迭代、经历了几次重构之后你会慢慢找到那种“这个聚合边界画得真舒服”的感觉——到那时候很多方法论之外的问题你自然就知道该怎么办了。