4. 事件驱动架构的典型模式

在银行核心系统与渠道系统解耦的过程中，事件驱动架构并非只有一种实现方式。不同业务场景对一致性、可追溯性、响应时效的要求差异很大，因此业界沉淀出若干典型模式。理解这些模式的原理与边界，是后续落地设计的前提。

一、五种模式的核心原理

事件通知是最轻量的模式。生产者只发布“发生了什么”这一事实，不携带业务数据，消费者收到通知后主动回查。它的优点是耦合度极低、事件体小；缺点是消费者需要额外查询，且存在查询时数据已变化的时序风险。

事件携带状态转移在事件中直接嵌入消费者所需的业务数据，消费者无需回查即可完成本地处理。它降低了查询依赖，但事件体变大，且生产者需要为下游的消费需求负责，容易造成事件契约膨胀。

事件溯源不保存聚合的当前状态，而是把状态变化本身作为唯一事实来源，通过顺序重放事件重建状态。它天然具备完整审计能力，非常适合银行账务、交易流水等强审计场景，但查询需要重建，且事件版本演进要求严格。

CQRS将命令侧（写模型）与查询侧（读模型）分离，写侧专注业务规则与一致性，读侧通过订阅事件构建面向查询的物化视图。它解决了读写负载与模型诉求不一致的问题，代价是引入了最终一致性与读模型维护成本。

Saga用于跨多个聚合或服务的长事务。它把全局事务拆为一串本地事务，每个本地事务都有对应的补偿操作；当某一步失败时，按反向顺序执行补偿，使系统回到业务可接受的状态。Saga 分为编排式与协同式两种组织方式。

二、方法流程：模式选择与落地步骤

1. 识别业务一致性边界：先划分聚合，明确哪些状态变化必须原子完成，哪些可以最终一致。
2. 判断事件用途：仅通知下游、需要携带数据、还是需要完整审计，分别对应事件通知、携带状态转移、事件溯源。
3. 评估读写诉求：若查询模型与写模型差异大、读多写少，引入 CQRS 构建读模型。
4. 识别跨聚合长事务：涉及多个服务或聚合的流程，用 Saga 编排本地事务与补偿。
5. 定义事件契约与版本策略：确定事件命名、字段、版本演进与兼容规则。
6. 建立可观测与补偿机制：对事件发布、消费、补偿执行进行监控与告警。

三、银行场景案例

以“客户转账”为例：转账命令进入写模型，校验余额与限额后产生TransferInitiated事件；账务聚合采用事件溯源，顺序记录Debited与Credited事件；查询侧通过 CQRS 订阅事件，构建“客户交易明细”读模型；若跨行清算涉及多个服务，则用 Saga 编排“扣款—清算—入账”，任一步失败则触发反向补偿。

事件序列示例：
TransferInitiated  ->  AccountDebited  ->  ClearingSubmitted
                   ->  AccountCredited ->  TransferCompleted
失败补偿路径：
ClearingFailed     ->  AccountDebitReversed -> TransferCancelled

四、常见误区与复盘