聚合根与领域事件：DDD 战术建模

Sun, 15 Mar 2026 00:00:00 +0000

银行核心系统里最容易被低估的概念，是「聚合」。很多人把 DDD 战术设计理解成「给实体加几个注解」，结果聚合越写越大，事务越来越长，最后把数据库和团队都拖垮。本文把聚合根和领域事件放回它们本来的位置：一致性边界的设计工具，以及领域向外界发声的窗口。

为什么需要聚合

领域模型不是一张 ER 图。ER 图关心「数据怎么存」，聚合关心「哪些数据必须在同一个事务里保持一致」。这两件事经常错位，而错位的代价在金融场景里格外昂贵——账务不平、状态错乱，往往不是因为算法错，而是因为一致性边界划错了。

一致性边界

聚合的第一性原理是：在边界之内，用强一致性保证业务规则不被破坏；在边界之外，用最终一致性传递变化。一个账户余额不能为负，这条规则必须在一个事务内被满足，所以它属于聚合内部。而「账户余额变动后通知风控」，则属于边界之外，交给领域事件。

经验法则：如果两条业务规则必须同时为真，它们大概率属于同一个聚合；如果可以接受短暂的不一致，它们就分属不同聚合。

聚合不是「大对象」

最常见的反模式，是把「客户」做成包含地址、联系人、合同、账户、画像的超级对象。它在概念上很完整，但在工程上是个灾难：每次改一个手机号，都要加载半个数据库，还要锁住一堆根本无关的数据。

聚合的边界应以事务一致性而非业务概念大小来划。概念上属于「同一个东西」的数据，未必需要在同一个事务里。

聚合根的设计原则

聚合根是聚合对外的唯一入口。外部只能持有聚合根的引用，不能直接操作聚合内部的实体或值对象。

引用靠 ID，不靠对象

跨聚合的关联，永远用标识符，而不是对象引用。聚合 A 不应直接持有聚合 B 的对象，否则两个聚合会被悄悄绑进同一事务。

public class Account {
 private final AccountId id; // 聚合根标识
 private final CustomerId ownerId; // 跨聚合引用：只存 ID
 private final Money balance;
 private final List<DomainEvent> pendingEvents = new ArrayList<>();

 public void withdraw(Money amount) {
 if (balance.isLessThan(amount)) {
 throw new InsufficientBalanceException(id);
 }
 balance = balance.subtract(amount);
 pendingEvents.add(new MoneyWithdrawn(id, amount, now()));
 }

 public List<DomainEvent> drainEvents() {
 var copy = new ArrayList<>(pendingEvents);
 pendingEvents.clear();
 return copy;
 }
}

工厂与仓储

复杂聚合的创建交给工厂，避免调用方掌握内部构造细节；聚合的持久化交给仓储，且仓储只按聚合根 ID 加载整个聚合，不存在「只查一半」的仓储方法。