聚合：一致性边界，不是 has-a 对象图

全章用一个贯穿示例钉概念：「云市」销售上下文里的核心聚合 Order（订单）。它内部有一组订单项 OrderLine、一个收货地址 ShippingAddress、若干金额 Money；它对外要引用买家、要引用库存。这个对象簇怎么切边界、谁能进、谁只能拿到 id——就是这一章的全部问题。先从组成聚合的两种零件说起：实体与值对象。

5.1实体 Entity：按标识相等，身份贯穿生命周期

实体（Entity）是一个有唯一标识、身份在整个生命周期里保持不变的对象——两个字段完全相同的实体，仍是两个不同的实体。

底层机制（比定义深一层）：实体的相等性只看标识。Order 的 equals 应该比较 orderId，绝不能比较"金额 + 买家 + 行项"。这条规则有两个直接后果。其一，实体可变是合法的——状态机推进、加减行项都在改字段，但它始终是同一个身份。其二，标识必须稳定且尽早分配：理想情况下在对象诞生那一刻就由工厂或领域生成 id，而不是等数据库 INSERT 回填——否则一个"还没有身份"的对象进了集合、进了 HashMap，等 id 回填时 hashCode 变了，它就在集合里"丢失"了。

与下一个概念的关系：实体回答"是哪一个"。但聚合里大量的零件——金额、地址、数量——业务并不关心"是哪一个"，只关心"是多少"。这类"无身份、按值论"的对象，是另一种建模角色：值对象。

5.2值对象 Value Object：按值相等、不可变、可安全共享

值对象（Value Object）没有标识，两个值对象只要字段全等就相等；它一旦构造就不可变，因此可以被多处安全共享与替换。

底层机制（比定义深一层）：值对象的三条性质互相支撑。按值相等意味着 equals/hashCode 比较全部字段；不可变意味着任何"修改"都返回一个新实例而非改原对象（plus() 返回新 Money）；可安全共享是前两条的推论——既然不可变，就不怕别人持有同一个引用后偷偷改坏它，于是可以放心地把同一个 Money 实例传给多个对象、放进多个集合。值对象还应当构造即自校验：ShippingAddress 在构造器里就校验省市区非空、邮编格式合法，造不出一个"非法的地址"。

public final class Money {
    private final BigDecimal amount;
    private final Currency currency;

    public Money(BigDecimal amount, Currency currency) {
        if (amount == null || currency == null)
            throw new IllegalArgumentException("amount/currency 不能为空");
        // 构造即自校验：金额按币种精度规整，造不出"非法的钱"
        this.amount   = amount.setScale(currency.getDefaultFractionDigits(), RoundingMode.UNNECESSARY);
        this.currency = currency;
    }

    // 任何"修改"都返回新实例，原对象不变 —— 这是"不可变"的落地
    public Money plus(Money other) {
        requireSameCurrency(other);          // 币种不同不能相加
        return new Money(this.amount.add(other.amount), this.currency);
    }

    public Money times(int qty) {
        return new Money(this.amount.multiply(BigDecimal.valueOf(qty)), this.currency);
    }

    private void requireSameCurrency(Money other) {
        if (!this.currency.equals(other.currency))
            throw new IllegalArgumentException("币种不同不能相加：" + currency + " vs " + other.currency);
    }

    // 按值相等：字段全等即相等，没有 id 这回事
    @Override public boolean equals(Object o) {
        if (this == o) return true;
        if (!(o instanceof Money)) return false;
        Money m = (Money) o;
        return amount.compareTo(m.amount) == 0 && currency.equals(m.currency);
    }
    @Override public int hashCode() { return Objects.hash(amount.stripTrailingZeros(), currency); }
}

对照实体看：Money 没有 id，equals 比的是字段而非标识；它的 plus 不改自己而是产出新 Money；币种不同直接抛异常，把"人民币加美元"这种非法状态挡在构造之外。01 章点过的贫血模型反例，正是把这些行为（加法、币种校验）从 Money 里抽走、塞进某个 Service，让 Money 退化成一个只有 getter 的数据袋。

与下一个概念的关系：实体和值对象是零件。把若干实体和值对象按 has-a 关系拼起来，得到的是一张对象图——而这正是要被重写的旧直觉。聚合不是这张图，它是从这张图上切出来的一条边界。

5.3聚合 Aggregate：一致性边界，不是 has-a 对象图

聚合（Aggregate）是一组实体和值对象的集群，它们被划进同一条一致性边界，作为整体被一起加载、一起保存、一起校验；其中一个实体被指定为聚合根 Aggregate Root，是边界唯一的外部入口。

底层机制（比定义深一层）：聚合的三条硬规则。第一，聚合根是唯一外部入口——外部代码只能通过 Order 调方法，不能拿到内部的 OrderLine 去单独改它。OrderLine 是聚合内部实体，没有对外暴露的全局身份。第二，根守护不变量——增删行项、推进状态都是根上的方法（order.addLine(...)、order.confirm()），方法内部维持总额一致、状态合法，外部无从绕过。第三，外部只能持有根的引用——别的聚合、别的服务想引用这张订单，只能拿 orderId，拿不到 OrderLine 指针。这条最反直觉，也是 5.6 节的主题。

这正是要重写的旧直觉：在常规分层里，"对象图"约等于"一张表关联图"，谁 join 得到谁就能改谁。04 章的事件风暴把这个问题前移了——墙上一簇"必须一起变更"的便利贴圈成一个黄色聚合，圈的依据从来不是外键关联，而是"这些东西的变更必须保持一致"。聚合边界 = 一致性边界，不是 has-a 边界。

与下一个概念的关系：知道了"聚合是一条边界、根是守门人"，下一个问题立刻冒出来——这条边界画到哪？把多少东西圈进来？答案不是"看 has-a 拉多深"，而是"看哪些不变量必须在同一瞬间成立"。

5.4真正不变量决定聚合大小

聚合该多大，由它必须守护的真正不变量（true invariant）决定：一条规则若必须在每次提交的瞬间都成立，相关数据就得进同一个聚合；若容忍几秒延迟，就该留在边界外。

底层机制（比定义深一层）：判别一条规则是不是真正不变量，做一个测试——"这条规则必须在提交那一瞬间成立，还是容忍几秒延迟也能接受？" 必须瞬间成立的，进边界；能容忍延迟的，是另一个聚合的事，走最终一致。拿「云市」的 Order 走一遍：

前三条是 Order 的真正不变量——它们彼此牵连、必须在同一次提交里一起成立，所以总额、行项、状态机三者必须同处一个聚合。第四条"库存够不够"很容易被误塞进来（毕竟下单"想当然"要扣库存），但它不要求在下单提交的瞬间成立：04 章那条事件流——下单发 OrderPlaced → 库存上下文异步预留 → 回 StockReserved——正是把库存判定放到边界外、用最终一致处理的证据。库存是 StockItem 这个独立聚合的职责，不在下单的同一事务里。

与下一个概念的关系：上面这道题里"共用一个 version、撞版本失败"的现象，不是实现细节，而是"一个事务一个聚合"这条规则的根因。下一节把它讲透。

5.5一个事务一个聚合：源自乐观锁的版本号单位

每个事务只修改一个聚合实例——这条规则不是教条，它源自一个机制事实：聚合是乐观锁的版本号单位，所以聚合的大小直接决定了并发争用的粒度。

底层机制（比定义深一层）：聚合通常带一个 version 字段（乐观锁版本号）。保存时数据库执行的是 UPDATE ... SET version = version + 1 WHERE id = ? AND version = ?——只有手里的版本号和库里一致才更新成功，否则说明有人先改了，本次提交失败重试。关键在于：这个版本号是整个聚合共用一个的。于是聚合的物理大小，就等于乐观锁冲突的粒度：

• 大聚合（Order + 全部 1000 行 + 支付 + 物流共用一个 version）：任何对这张订单任意角落的并发编辑，都在抢同一个版本号。两笔无关的修改（改第 3 行 / 改第 900 行）也会撞版本、失败、重试——它变成了争用热点。
• 小聚合（把支付、物流拆成各自的聚合，订单只留必须强一致的核心）：每个聚合各有各的 version，锁的足迹小，无关编辑落在不同版本号上、互不冲突，并发吞吐显著提高。

这条机制反过来回答了 5.4 的尺度问题：之所以要让聚合"尽量小、只圈真正不变量"，正是因为聚合越大、版本号争用越凶。02 章把销售定为核心域——核心域恰恰是并发最密、最经不起争用的地方，所以核心聚合的"小"尤其要紧。

与下一个概念的关系：要把聚合做小、把别的东西推到边界外，就必须解决一个问题——订单明明"业务上关联"买家和商品，怎么在不把它们拖进同一事务的前提下引用它们？答案是只持 id，不持对象。

5.6按标识引用 Reference by Identity：只持 id，不持对象指针

一个聚合引用另一个聚合时，只持有对方的标识（id），不持有对方的对象指针：Order 持 buyerId、OrderLine 持 skuId，而不是 Customer/Product 对象。

底层机制（比定义深一层）：对象指针是"会自己长大"的引用。order.getBuyer().getMemberLevel() 这一行看着无害，但它要求 Buyer 此刻就在内存里、就在本事务里——于是 Buyer 被加载、被纳入当前持久化上下文、它的修改也可能被一并 flush。改成 order.getBuyerId()，引用退化成一个值，跨不出去：想知道买家等级，必须显式 buyerRepository.byId(buyerId)，这次显式查询是另一个聚合、另一段一致性边界的事，与下单事务无关。按 id 引用，就是用"显式的不便"换"边界的清晰"。

public class Order {                       // 聚合根（实体，按 orderId 相等）
    private final OrderId id;
    private final BuyerId buyerId;         // ← 按 id 引用外部聚合，不是 Customer 对象
    private final List<OrderLine> lines = new ArrayList<>();
    private Money total;                   // 值对象
    private OrderStatus status;            // CREATED→CONFIRMED→PAID→SHIPPED→COMPLETED
    private long version;                  // ← 乐观锁版本号，整个聚合共用一个

    // 工厂保证产出的 Order 已满足全部不变量
    public static Order place(OrderId id, BuyerId buyerId, List<OrderLine> lines) {
        Order o = new Order(id, buyerId);
        lines.forEach(o::addLine);         // 经过 addLine 维持总额一致
        o.status = OrderStatus.CREATED;
        return o;
    }

    // 唯一的加行入口：外部拿不到 lines 直接 add，只能走这里 —— 不变量①总额一致
    public void addLine(OrderLine line) {
        requireState(OrderStatus.CREATED);
        lines.add(line);
        this.total = recomputeTotal();     // 总额 = Σ(行单价 × 数量)，提交瞬间成立
    }

    // 状态机单向推进 —— 不变量②确认后行项非空、不变量③状态合法
    public void confirm() {
        requireState(OrderStatus.CREATED);
        if (lines.isEmpty())
            throw new IllegalStateException("确认的订单不能没有行项");
        this.status = OrderStatus.CONFIRMED;
    }

    private Money recomputeTotal() {
        return lines.stream()
                    .map(OrderLine::subtotal)        // 每行 unitPrice.times(qty)
                    .reduce(Money.zero(CNY), Money::plus);
    }
    private void requireState(OrderStatus expected) {
        if (this.status != expected)
            throw new IllegalStateException("非法状态跃迁：" + status + " → " + expected);
    }
}

public class OrderLine {                   // 聚合内部实体，无对外全局身份
    private final SkuId skuId;             // ← 按 id 引用商品/SKU，不是 Product 对象
    private final Money unitPrice;         // 下单时冻结的单价快照（值对象）
    private final int qty;
    Money subtotal() { return unitPrice.times(qty); }
}

逐点对照（代码 → 概念）：

• buyerId / skuId 是 id 而非对象——引用在边界处断开，加载 Order 不会顺带把 Buyer、Product 拖进事务（5.6 的核心）。
• addLine / confirm 是根上唯一的修改入口，内部维持总额一致、行项非空、状态合法——三条真正不变量的执行点（5.3 + 5.4）。
• version 整个聚合共用一个——它就是 5.5 里乐观锁较劲的那个版本号。
• unitPrice 是下单时冻结的单价快照，呼应 03 章的一词多义：同一个"商品"，在目录上下文是胖展示对象，到了销售上下文只是一份价格被冻结的快照。