1. 课程导入

银行交易系统是典型的“高价值、强一致、强审计”业务系统。一次转账看似只是账户余额的加减，背后却涉及记账、清算、风控、对账、审计、监管报送等多个环节。传统以“当前状态”为中心的建模方式，在业务复杂度上升后，会逐渐暴露出可追溯性差、状态变更语义丢失、跨系统协同困难等问题。本章作为课程导入，先建立问题意识，再引出事件溯源（Event Sourcing）的核心价值，并给出整体学习框架。

一、银行交易系统的真实挑战

在传统 CRUD 模型中，我们通常只保存账户的最终余额，例如 balance = 10000。但银行真正关心的往往不是“现在是多少”，而是“为什么是这么多”。当客户投诉、监管检查或系统对账出现差异时，仅凭最终状态很难还原完整过程。

• 审计与合规压力：监管要求交易可追溯、不可篡改、可重放，传统更新式存储容易覆盖历史。
• 状态语义丢失：余额从 10000 变为 9000，可能是转账、手续费、冲正或冻结，单看结果无法区分。
• 并发与一致性：同一账户在高并发下可能出现更新丢失、重复扣款、顺序错乱。
• 跨系统协同：核心账务、支付网关、风控、积分、通知等系统对同一笔交易的理解不一致。
• 故障恢复困难：一旦数据被错误更新，缺少“事件日志”作为事实来源，恢复成本极高。

二、事件溯源的核心原理

事件溯源的核心思想是：不保存最终状态，而是保存导致状态变化的所有事件。当前状态由事件按顺序重放（Replay）计算得出。对于银行交易而言，每一笔转账、存款、取款、冲正、冻结都是一条不可变事件。

例如，一个账户的事件流可能如下：

AccountOpened     { accountId: "A1001", owner: "张三", at: "2025-01-01T09:00:00" }
MoneyDeposited    { accountId: "A1001", amount: 10000, at: "2025-01-02T10:00:00" }
MoneyWithdrawn    { accountId: "A1001", amount: 2000,  at: "2025-01-03T14:30:00" }
TransferOut       { accountId: "A1001", target: "A1002", amount: 3000, at: "2025-01-04T11:00:00" }
TransferReversed  { accountId: "A1001", target: "A1002", amount: 3000, at: "2025-01-05T09:15:00" }

通过重放这些事件，系统可以计算出任意时间点的余额，也可以回答“这笔钱为什么被扣”。事件一旦写入，不允许修改，只能追加，从而形成天然审计日志。

三、方法流程：从命令到事件再到视图

在事件溯源架构中，一次银行交易通常遵循“命令—事件—状态—视图”的流转路径。命令表示意图，事件表示已发生的事实，状态由事件重放得到，视图则面向查询和下游消费。

1. 接收命令：如“转账 3000 元”，系统先做校验，包括余额、限额、风控规则。
2. 生成事件：校验通过后，生成 TransferOut 事件，并追加到事件存储。
3. 持久化事件：事件写入事件库，保证顺序性和不可变性。
4. 更新聚合状态：聚合根根据事件更新内存状态，得到最新余额。
5. 发布事件：通过消息总线通知下游，生成读模型或触发其他业务。
6. 构建视图：查询侧订阅事件，维护余额表、流水表、风控指标等。

对比维度	传统 CRUD	事件溯源
存储内容	当前状态快照	不可变事件序列
审计能力	依赖额外日志	事件即审计日志
状态还原	无法还原历史	可重放到任意时间点
并发处理	易发生更新冲突	基于事件版本控制
下游协同	需额外同步	事件天然可订阅

四、案例场景：一笔转账的完整生命周期

假设客户张三向李四转账 3000 元。传统系统可能只更新两个账户余额，而事件溯源会记录完整事实链：

1. TransferRequested  { from: "A1001", to: "A1002", amount: 3000 }
2. TransferDebited    { account: "A1001", amount: 3000, balanceAfter: 5000 }
3. TransferCredited   { account: "A1002", amount: 3000, balanceAfter: 8000 }
4. TransferCompleted  { transferId: "T20250104001", status: "SUCCESS" }

如果后续发现该笔转账异常，可以追加 TransferReversed 事件，而不是删除或修改原事件。这样既保留了历史，又满足冲正需求。对账系统、风控系统、审计系统都可以基于同一事件流构建各自视图，避免“各系统数据不一致”的经典问题。

五、常见误区与复盘

• 误区一：事件溯源等于消息队列。消息队列只是传输机制，事件溯源强调事件作为事实来源被持久化。
• 误区二：事件可以修改或删除。事件不可变，错误应通过补偿事件修正，而不是覆盖历史。
• 误区三：所有查询都直接重放事件。实际系统通常结合快照和读模型，避免每次查询都全量重放。
• 误区四：忽略事件版本与兼容性。事件结构会演进，必须设计版本策略和向后兼容方案。

六、学习目标与整体课程框架

通过本课程，你将掌握事件溯源在银行交易系统中的完整落地方法。学习目标包括：

• 理解事件溯源的核心概念、适用边界与银行场景价值。
• 掌握事件建模、聚合设计、事件存储与快照策略。
• 能够设计命令处理、事件发布、读模型构建与查询分离。
• 掌握并发控制、幂等、版本管理、事件回放与故障恢复。
• 能够结合银行转账、存款、冲正、对账等场景完成实战实现。

整体课程将围绕“概念—建模—存储—并发—查询—实战—运维”展开，逐步从理论走向可运行系统。本章作为导入，重点是建立问题意识和整体认知：银行交易系统需要的不仅是余额，更是可追溯、可解释、可重放的事实链。事件溯源正是围绕这一目标组织系统架构的方法论。