1. 课程导学：分布式事务的挑战与事件风暴的价值
在微服务与云原生架构成为主流的今天，分布式事务已经从“偶发问题”演变为“系统级顽疾”。本课程将带你从事件风暴（Event Storming）这一协作建模方法出发，系统性地解决分布式事务的设计与落地难题。本章作为导学，首先剖析分布式事务的核心挑战，再揭示事件风暴为何能成为破解困局的关键工具。
1.1 分布式事务的四大核心挑战
分布式事务的本质是跨多个独立数据源或服务的原子性操作保障。在单体架构中，本地数据库事务（ACID）即可解决；但在分布式环境下，网络延迟、服务宕机、数据不一致等问题使得传统事务模型难以直接适用。以下是实践中最常见的四大挑战：
| 挑战维度 | 具体表现 | 典型后果 |
|---|---|---|
| 一致性模型冲突 | 强一致性（ACID）与最终一致性（BASE）的选择困境 | 业务逻辑复杂化，数据短暂不一致导致用户投诉 |
| 网络与故障不确定性 | 服务调用超时、节点宕机、消息丢失或重复 | 事务悬挂、部分提交、补偿逻辑难以闭环 |
| 跨服务状态管理 | 每个服务拥有独立数据库，无法使用全局锁或分布式XA | 数据孤岛，查询与对账成本急剧上升 |
| 业务与技术的认知鸿沟 | 业务专家描述“下单即扣库存”，开发实现却涉及3个服务、2个MQ、1个定时任务 | 需求理解偏差，上线后频繁出现数据不一致Bug |
关键认知： 分布式事务没有“银弹”。选择2PC、TCC、Saga还是消息最终一致性，取决于业务场景对一致性、可用性、吞吐量的具体权衡。而事件风暴正是帮助团队在编码之前做出正确权衡的建模工具。
1.2 传统分布式事务方案的局限性
在引入事件风暴之前，我们先回顾业界常见的分布式事务方案及其痛点：
- 两阶段提交（2PC/XA）： 强一致性，但性能差、阻塞时间长、协调器单点故障，不适合高并发微服务。
- TCC（Try-Confirm-Cancel）： 业务侵入性强，每个服务需实现Try、Confirm、Cancel三组接口，开发成本高。
- Saga（编排/协同）： 适合长事务，但缺乏全局隔离性，补偿逻辑设计不当易导致数据污染。
- 消息最终一致性（本地消息表/RocketMQ事务消息）： 异步解耦，但消息顺序、幂等、死信处理等细节极易出错。
这些方案在技术层面各有优劣，但一个更根本的问题被长期忽视：团队是否真正理解了业务全流程中的“事务边界”和“一致性需求”？ 如果业务建模阶段就存在模糊地带，任何技术方案都无法保证最终的数据正确性。
1.3 事件风暴：从业务混沌到架构清晰
事件风暴是由Alberto Brandolini提出的一种协作式领域建模方法。它通过“领域事件”作为核心驱动，让业务专家与开发团队在短时间内对齐认知，并直接产出聚合、限界上下文、命令、读模型等DDD（领域驱动设计）核心要素。对于分布式事务设计，事件风暴的价值体现在以下三个层面：
- 发现真实的事务边界： 通过时间线梳理“事件流”，识别哪些操作必须在一个本地事务内完成，哪些可以异步最终一致。
- 暴露隐式补偿逻辑： 当某个领域事件触发失败时，业务专家会自然描述“如果……就……”，这正是Saga补偿或TCC Cancel的原始需求。
- 消除认知偏差： 所有参与者站在同一张“事件风暴画布”前讨论，避免“我以为你懂了”的沟通陷阱。
课程实践提示： 本课程后续章节将带领你使用事件风暴画布，从零开始为电商、支付、库存等典型场景设计分布式事务方案。你不需要是DDD专家，只需要带着业务问题和团队一起“贴便签”。
1.4 事件风暴画布与分布式事务的映射关系
下图展示了事件风暴画布中的核心元素如何映射到分布式事务的设计决策：
1.5 本课程的学习路径与实战目标
《Go工程实战：分布式事务事件风暴画布架构设计》共30章，分为四个阶段：
- 阶段一（第1-5章）： 分布式事务基础与事件风暴建模入门。掌握核心概念，完成第一个“订单-库存”事件风暴工作坊。
- 阶段二（第6-15章）： 画布实战：从事件流推导出Saga、TCC、事务消息方案。每个方案都配有Go代码实现与单元测试。
- 阶段三（第16-25章）： 高级主题：幂等设计、隔离性提升、分布式事务监控与对账、多活场景下的跨机房事务。
- 阶段四（第26-30章）： 综合案例：基于事件风暴画布重构一个真实的电商交易系统，覆盖下单、支付、库存、积分全链路。
学习前置要求： 你需要具备Go语言基础（至少能读懂Goroutine和channel），了解基本的REST/gRPC通信模式。不需要预先掌握DDD或事件风暴，课程会从零引导。