实战项目：基于Go的分布式事务事件风暴画布订单系统 - 第1节

1.1 分布式事务：从单体到微服务的挑战

在单体应用时代，事务由数据库的 ACID 特性保障：BEGIN TRANSACTION 到 COMMIT 之间，数据要么全部成功，要么全部回滚。进入微服务架构后，业务逻辑被拆分为多个独立服务，每个服务拥有自己的数据库实例，传统的本地事务无法跨越服务边界。

1.1.1 分布式事务的三种典型场景

1.2 事件风暴画布：让复杂业务可视化

事件风暴（Event Storming） 是由 Alberto Brandolini 提出的一种协作建模方法，通过“事件”驱动，让领域专家、开发人员、产品经理在同一张画布上快速对齐业务全貌。本课程将事件风暴画布作为分布式事务设计的核心工具。

1.2.1 画布中的核心元素

• 领域事件（Domain Event）：已发生的业务事实，如 订单已创建、库存已扣减。用橙色便签表示。
• 命令（Command）：触发事件的用户操作或系统指令，如 提交订单。用蓝色便签表示。
• 聚合（Aggregate）：保证事务一致性的数据边界，如 订单聚合。用黄色便签表示。
• 外部系统（External System）：支付网关、物流平台等第三方服务。用粉色便签表示。
• 策略（Policy）：事件触发后的自动响应规则，如 订单超时自动取消。用紫色便签表示。

1.3 订单系统业务场景总览

本课程实战项目构建一个完整的 B2C 电商订单系统，覆盖从用户下单到订单完成的完整生命周期。系统涉及 6 个核心微服务，每个服务独立部署、独立数据库。

1.3.1 核心服务与职责

1.3.2 核心业务流程：下单事务

1. 用户提交订单：订单服务创建订单记录，状态为“待支付”。
2. 预占库存：订单服务调用库存服务，尝试扣减商品库存。若库存不足，订单创建失败。
3. 冻结余额：订单服务调用账户服务，冻结用户账户中对应的金额。
4. 返回支付链接：库存和余额都成功处理后，订单服务返回支付二维码/链接给用户。
5. 用户支付：用户通过支付网关完成支付，支付服务接收异步回调。
6. 最终确认：支付成功后，订单状态更新为“已支付”，库存正式扣减，余额正式扣除。

1.4 课程目标与学习路径

1.4.1 你将掌握的核心能力

• 事件风暴建模：独立完成订单系统的领域事件、命令、聚合识别，输出可落地的画布。
• 分布式事务设计：理解 2PC、TCC、Saga、本地消息表等模式，并能在 Go 中实现。
• Go 工程实践：使用 Go 1.22+、gRPC、Kafka、PostgreSQL 构建生产级微服务。
• 事务补偿与监控：设计回滚策略、幂等方案、事务日志与告警。

1.4.2 学习路径图

1.4.3 每章交付物清单