领域事件：跨聚合协同与最终一致

全章用「云市」的下单主线钉概念：买家在销售上下文（Sales）提交一个 Order 聚合，库存上下文（Inventory）里有独立的 StockItem 聚合要为这笔订单预留库存。05 章已经定下规矩——下单不在同一事务里扣库存，因为 Order 和 StockItem 是两个聚合。本章回答的就是那个被推迟的问题：既然不在一个事务里，这两个聚合靠什么协同。

7.1领域事件 Domain Event：陈述"确实发生过的事"

领域事件：领域中确实发生过的、有业务意义的事实，用过去式命名、内容不可变（OrderPlaced / OrderPaid / StockReserved）。

为什么是过去式：领域事件描述的是已经发生、无法撤回的事。OrderPlaced（订单已下单）不是"请下单"——下单这个动作已经完成、不变量已经满足、状态已经落库，事件只是把这个既成事实播报出去。命名用过去式分词（Placed / Paid / Reserved）是一条硬纪律：它在语法上就堵死了"把事件当命令使"的误用。命令（Command）可以被拒绝（"下单"可能因风控失败），事件不能被拒绝——它陈述的是历史，历史只能被响应，不能被否决。

为什么不可变：既然是历史事实，它的内容就不该再变。事件一旦发出，可能被多个处理方读到、可能被存档、可能在重放时再次经过。如果谁能改它的字段，"同一个事实在不同地方读出不同值"就会发生。所以领域事件的所有字段都是 final，构造即定型，没有 setter。它还带一个发生时刻（occurredOn）——事实总是发生在某个时间点上。

// 领域事件：陈述"订单已下单"这一既成事实
// 命名用过去分词 Placed；所有字段 final；只读，不可改
public final class OrderPlaced {
    private final String orderId;
    private final String buyerId;
    private final List<ReservedLine> lines;   // skuId + 数量的只读快照
    private final Instant occurredOn;           // 事实发生的时刻

    public OrderPlaced(String orderId, String buyerId, List<ReservedLine> lines) {
        this.orderId = orderId;
        this.buyerId = buyerId;
        this.lines = List.copyOf(lines);        // 防御性拷贝，外部改不动
        this.occurredOn = Instant.now();
    }
    // 只有 getter，没有任何 setter
    public String orderId()       { return orderId; }
    public String buyerId()       { return buyerId; }
    public List<ReservedLine> lines() { return lines; }
    public Instant occurredOn()   { return occurredOn; }
}

事件由谁产生？由聚合根。状态在聚合内合法地改变（订单从 CREATED 转到 CONFIRMED），聚合就在内部记一笔"我刚刚发生了 OrderPlaced"，先攒着，等所在事务提交后再统一对外发布。这样事件和它描述的状态变更落在同一个事务边界里——不会出现"事件发了，但订单根本没存进去"的鬼故事。

public class Order {  // 聚合根
    private OrderId id;
    private OrderStatus status;
    private final List<OrderLine> lines = new ArrayList<>();
    private final List<Object> domainEvents = new ArrayList<>();  // 暂存区

    // 静态工厂：产出的 Order 已满足全部不变量（见 06 章）
    public static Order place(String buyerId, List<OrderLine> lines, PricingService pricing) {
        Order order = new Order(buyerId, lines, pricing);   // 校验非空、金额一致
        order.status = OrderStatus.CONFIRMED;
        // 状态合法改变后，记录一笔已发生的事实
        order.domainEvents.add(new OrderPlaced(order.id.value(), buyerId, snapshot(lines)));
        return order;
    }

    // 提交后由应用服务取走并清空——事件随事务一起对外
    public List<Object> pullDomainEvents() {
        List<Object> copy = List.copyOf(domainEvents);
        domainEvents.clear();
        return copy;
    }
}

与下一节的关系：事件发出去了，谁来接、接了之后那两个聚合的状态怎么对上号？这就要引入"短暂不一致、随后收敛"——最终一致性。

7.2最终一致性 Eventual Consistency：两个小事务 + 中间一个事件

最终一致性：跨聚合的状态允许短暂不一致，经过一段（通常很短的）延迟后收敛到一致。

主线机制（一步步走「云市」下单）：

1. 事务 ①（Sales）：应用服务造出 Order、orderRepository.add(order)，同一事务里发布 OrderPlaced。提交那一刻，订单已落库、状态 CONFIRMED，但库存还没动——此刻系统处于"不一致"窗口：订单说要 3 件，库存还没扣。
2. 异步传递：OrderPlaced 被投递给库存上下文的处理器。进程内可以是事务提交后的回调，跨进程则走消息中间件。
3. 事务 ②（Inventory）：处理器在自己独立的事务里加载对应的 StockItem 聚合，调 reserve(qty) 预留库存。成功就提交，并发布 StockReserved；可用量不足则发布 StockReservationFailed。
4. 事务 ③（Sales）：StockReserved 回到销售上下文，处理器加载 Order，把它标记为"可支付"。至此两个聚合的状态收敛——不一致窗口闭合。

关键在于：任何一个时刻都不存在跨两个聚合的事务。每个事务只锁一个聚合、只保证那个聚合自身的不变量。聚合之间的一致性，由事件链在时间上"最终"达成。下单的买家不会因为库存上下文慢半秒就被卡住——订单先成立，库存随后跟上。

与下一节的关系：到底哪些跨聚合协同该走最终一致、哪些必须事务一致？这不是凭手感拍板，Vernon 给了一条能落到组织上的判定规则。

7.3Vernon 的"谁的职责"规则：把技术问题还原成组织问题

判据：发命令的人，是否必须在自己这次操作里立刻看到规则被满足？是 → 事务一致（同一聚合）；否（那是别人的职责）→ 最终一致。

怎么用这条规则（拿「云市」两个情形对照）：

情形 A：删一个订单项，订单总额要不要立刻对？买家在订单里删掉一行，Order 的不变量是"总额 == Σ(行单价 × 数量)"（05 章的真正不变量）。删行的人就是订单的负责人，他必须在这次操作里立刻看到总额变对——总额慢半秒才更新是不可接受的 bug。结论：这是同一个人、同一个职责，必须事务一致，而总额和订单项本来就在同一个 Order 聚合里，一个事务天然搞定。

情形 B：下单后，库存要不要立刻扣？买家点"下单"，他要确认的是"我的订单成立了"。库存够不够、扣没扣，那是仓库（库存上下文）的职责，不是买家这次操作必须当场盯着的规则。买家不必、也不应该被库存系统的快慢绑住。结论：不同职责 → 最终一致，正是 7.2 的主线。

这条规则最锋利的地方在于：它把"要不要上分布式事务 / ACID vs 异步"这个看起来纯技术的问题，翻译成了一个组织问题——"这条规则到底归谁管，他需不需要当场看到结果"。一旦边界划到了人和职责上，技术选型几乎是自动落下来的。同一职责内的不变量进同一个聚合、走事务一致；跨职责的协同走事件、走最终一致。

与下一节的关系：上面说"跨职责走事件"，很多人立刻联想到 Kafka、消息总线、微服务。但"需要领域事件"和"需要一套事件驱动架构"是两件事，混为一谈会带来过度设计。

7.4领域事件 ≠ 事件驱动架构 EDA：建模概念 vs 部署风格

领域事件是建模概念（领域里发生了什么），事件驱动架构（Event-Driven Architecture, EDA）是部署/集成风格（系统间靠消息异步通信）；要前者不等于要后者。

两个不同层次的东西：

• 领域事件（概念层）：OrderPlaced 这个类、它表达的业务事实、它在统一语言里的名字。它是建模产物，和你用什么技术投递无关。
• 事件驱动架构 EDA（部署层）：用消息中间件（Kafka / RabbitMQ）让多个服务/上下文异步通信的集成风格。它解决的是分布式、解耦部署、跨网络可靠投递的问题。

该怎么落（从轻到重）：同一个 OrderPlaced，投递方式可以随系统形态升级，概念本身不变。

• 进程内先发：销售和库存还在同一个单体里时，事务提交后用一个进程内的事件分发器（Spring 的 ApplicationEventPublisher 之类）把 OrderPlaced 派给同进程的处理器即可。同步或异步线程都行，零中间件。
• 跨上下文 / 跨服务再上消息中间件：当库存真的拆成独立服务、跨网络部署，才把 OrderPlaced 序列化发到 Kafka，由库存服务订阅。这时你才需要 EDA 那一整套（分区、消费位点、重试、死信）。

顺序是概念先行、基础设施后补：先在领域里识别出哪些是事件、谁发谁收（这是建模），再根据部署边界决定投递机制（这是技术）。反过来——先架好 Kafka 再去想"往里发什么事件"——往往造出一堆贫乏的、没有领域含义的消息。

与下一节的关系：无论进程内还是跨服务，只要投递是异步的，就要面对三件落地问题：流程怎么编排、消息重复了怎么办、失败了怎么收场。

7.5落地细节：Saga、幂等、补偿

异步事件链落地要解决三件事：用 Saga / 流程管理器编排多步、用幂等抵御重复投递、用补偿动作回收失败。

Saga / 流程管理器：谁来推进这条链

下单 → 预留 → 标记可支付（失败则取消）是一个跨多个聚合、由事件串起来的长流程。Saga（一种把长事务拆成"一串本地事务 + 对应补偿"的模式）就是这条链的协调者。落地常是一个流程管理器（Process Manager）：它订阅链路上的各个事件，维护"这笔订单走到哪一步"的状态，并决定下一步发什么命令。它本身不含核心领域规则，只负责编排——和 06 章的应用服务一样是"零业务规则的协调者"，区别是它跨越多个事务、有自己的进度状态。

幂等处理：同一条事件来两次也只生效一次

异步投递几乎都是"至少一次"——网络抖动、消费者重启都会让 StockReserved 被投递两遍。如果处理器每收到一次就把订单往前推一步，订单可能被重复标记、库存可能被重复扣。幂等（idempotent）要求：同一个事件处理一次和处理 N 次，结果相同。做法是给每个事件一个幂等键（事件 id，或"业务键 + 步骤"），处理器先查这个键是否已处理过，处理过就直接跳过。

// 处理 OrderPlaced：在自己独立的事务里预留库存
// REQUIRES_NEW —— 与销售上下文的事务彻底分开，各锁各的聚合
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void on(OrderPlaced event) {
    // 幂等键：同一个事件投递多次，只生效第一次
    String idempotencyKey = "reserve:" + event.orderId();
    if (processedEvents.exists(idempotencyKey)) {
        return;   // 已处理过，直接跳过——重复投递无副作用
    }

    for (ReservedLine line : event.lines()) {
        StockItem item = stockRepository.stockOfSku(line.skuId());  // 加载库存聚合
        item.reserve(line.qty());            // 聚合内保证"预留不超过可用量"的不变量
        stockRepository.save(item);
    }
    processedEvents.mark(idempotencyKey);    // 落幂等键，和上面的预留同一事务提交

    eventPublisher.publish(new StockReserved(event.orderId()));   // 发布下一环事件
}

幂等键和业务动作要在同一个事务里落库，否则会出现"库存扣了但幂等键没记上"——下次重投又扣一遍。把 mark(key) 和 reserve() 绑进事务②，重复投递才真正无害。

补偿动作：失败了用新动作抵消，不是回滚

跨聚合没有大事务可回滚（7.2 想一想里已经走过一遍）。当 reserve() 因可用量不足失败，库存上下文发布 StockReservationFailed，销售上下文在又一个独立事务里执行补偿动作：把 Order 标记为取消或待补货、释放任何已占用的资源、通知买家。补偿是"对已提交的业务影响做一笔抵消记录"，语义上和会计的"红冲"一致——原动作留痕，再加一笔反向动作把它的效果抵掉。这也回应了过去式不可变那条：历史不能擦掉，只能用新的历史去纠正。