1. 课程导入
欢迎进入《银行事件驱动架构与领域事件设计实战》。在开始具体技术细节之前，我们需要先建立一张清晰的“认知地图”：为什么银行系统需要事件驱动架构，它解决什么问题，我们将沿着怎样的路径从概念走向落地。本章不涉及复杂代码，但会决定你后续29章的学习效率。
一、为什么银行系统必须关注事件驱动架构
传统银行核心系统长期以“请求—响应”和“批量日终”为主。客户转账、贷款审批、风控决策、积分累计、账单生成，往往通过同步调用和定时批处理串联。这种模式在交易量可控、渠道单一的时代是有效的，但今天面临三个根本性挑战：
- 实时性要求：反欺诈需要在毫秒级判断一笔支付是否放行，而不是等日终批量跑完。
- 系统解耦：一个转账动作可能触发记账、通知、积分、风控、监管报送等十几个下游动作，同步调用链会形成“牵一发动全身”的脆弱结构。
- 可追溯与可重放：监管审计要求每一笔资金变动都有完整证据链，且能在故障后重建状态。
事件驱动架构（Event-Driven Architecture，EDA）的核心思想是：把“发生了什么”作为一等公民。系统不再只传递“请做什么”的命令，而是发布“已经发生了什么”的事实。下游系统根据事件自主决策，从而实现时间解耦、空间解耦和逻辑解耦。
核心原理：事件是过去时的事实，命令是现在时的请求。银行领域事件（Domain Event）描述的是业务上已经发生、不可变、可追溯的关键状态变化，例如“账户已扣款”“贷款已审批通过”“客户风险等级已变更”。
二、学习目标与核心价值
完成本课程后，你应当能够独立完成以下任务：
- 识别银行核心业务中的领域事件，区分事件、命令与查询。
- 设计事件契约（Schema），包括事件类型、版本、元数据与幂等键。
- 选择合适的事件传输与存储机制，如 Kafka、Pulsar、RabbitMQ 或银行内部消息总线。
- 处理事件驱动架构中的一致性、顺序性、重复消费与死信问题。
- 将事件驱动架构与领域驱动设计（DDD）、CQRS、Saga 模式结合落地。
核心价值可以概括为“三升一降”：提升实时响应能力、提升系统可扩展性、提升审计可追溯性，降低系统间耦合度。对银行而言，这直接关系到客户体验、风险控制和监管合规。
三、整体知识框架
本课程的知识框架分为四层，从下到上依次是：
| 层级 | 核心内容 | 关键产出 |
|---|---|---|
| 业务层 | 银行领域建模、事件风暴、限界上下文 | 领域事件清单、上下文映射图 |
| 设计层 | 事件契约、版本策略、幂等与顺序设计 | 事件 Schema、契约文档 |
| 技术层 | 消息中间件、事件存储、Schema Registry | Topic 规划、分区策略、消费组设计 |
| 治理层 | 可观测性、死信处理、重放与审计 | 监控看板、重放预案、审计日志 |
这四层不是孤立的。业务层决定“发什么事件”，设计层决定“事件长什么样”，技术层决定“事件怎么传”，治理层决定“事件出问题怎么办”。后续章节会逐层展开。
四、实战路线图与常见误区
本课程的实战路线遵循“先业务、后技术，先设计、后治理”的顺序。很多团队一上来就选 Kafka、建 Topic，结果事件定义混乱、版本失控、下游无法消费。正确的顺序是：
- 事件风暴工作坊：业务专家与技术团队一起梳理关键业务流程，识别领域事件。
- 事件契约设计：为每个事件定义名称、字段、类型、版本和幂等键。
- 技术选型与拓扑设计：根据吞吐、顺序、延迟要求选择中间件和分区策略。
- 消费者设计与一致性保障：实现幂等消费、重试、死信和补偿。
- 可观测性与重放：建立监控、告警和事件重放机制。
常见误区：把事件当命令用，例如发布“请扣款”而不是“已扣款”；事件粒度过细导致消息爆炸；忽略事件版本兼容性；消费者不做幂等，重复消费造成重复记账。这些问题在后续章节会逐一拆解。
学习建议：每学完一个模块，回到自己熟悉的银行场景中找一个例子。例如“客户转账”可以拆出“转账已受理”“账户已扣款”“账户已入账”“转账已完成”等事件。带着真实场景学习，效果远好于只看理论。
接下来，我们将从银行领域建模开始，逐步构建完整的事件驱动架构能力。请先记住一句话：事件是银行系统的时间线，设计好事件，就设计好了系统的未来。