1. 课程导论：为什么需要事件驱动架构？
1.1 传统架构的痛点：从一次“订单超时”事故说起
假设你正在构建一个电商系统的“提交订单”功能。在传统的单体或分层架构中，一次下单操作通常需要同步调用多个服务：
- 创建订单（写入订单数据库）
- 扣减库存（调用库存服务）
- 发送短信通知（调用短信网关）
- 推送物流信息（调用物流系统）
典型问题：当短信网关响应超时（例如 5 秒），整个 HTTP 请求被阻塞。用户看到“订单提交中”的转圈动画，而库存已被扣减但订单状态未确认。最终导致：用户体验差、库存数据不一致、系统吞吐量骤降。
这种同步耦合架构在业务复杂度上升时，会暴露更多缺陷：
| 维度 | 传统同步架构 | 问题表现 |
|---|---|---|
| 可用性 | 强依赖链 | 下游服务故障直接导致上游失败 |
| 扩展性 | 垂直扩展为主 | 无法独立扩缩容瓶颈服务 |
| 一致性 | 本地事务 + 分布式事务 | XA 事务性能差，Saga 实现复杂 |
| 可观测性 | 请求链路追踪 | 跨服务调用链过长，排障困难 |
| 业务变更 | 修改接口 + 重新部署 | 牵一发而动全身，回归测试成本高 |
1.2 事件驱动架构（EDA）的核心思想
事件驱动架构将系统内部的状态变更抽象为不可变的事件（Event）。服务之间不再直接调用接口，而是通过事件总线（Event Bus / Message Broker）进行异步通信。
1.3 事件驱动架构的核心优势
| 优势 | 说明 | 业务价值 |
|---|---|---|
| 松耦合 | 服务只感知事件类型，不感知具体消费者 | 独立开发、测试、部署 |
| 高可用 | 事件持久化在消息队列中，消费者可离线恢复 | 故障隔离，系统韧性增强 |
| 弹性扩展 | 消费者可独立扩缩容，按吞吐量调整实例数 | 应对流量峰值，降低资源成本 |
| 最终一致性 | 通过事件重放和补偿机制保证数据一致 | 避免分布式事务，提升性能 |
| 审计溯源 | 事件日志天然记录所有状态变更 | 满足合规要求，方便问题排查 |
1.4 事件溯源（Event Sourcing）的引入
事件驱动架构解决了服务间通信的解耦问题，但数据库中的状态仍然是“当前快照”。当我们需要知道“订单为什么变成已取消”时，只能从业务日志中拼凑信息。
事件溯源（Event Sourcing）将这一思想推向极致：不存储当前状态，只存储状态变更的事件序列。任何当前状态都可以通过重放事件计算得出。
关键区别：
- 传统 CRUD： UPDATE orders SET status = 'cancelled' WHERE id = 123;（丢失历史）
- 事件溯源： 追加一条 OrderCancelled 事件到事件流中（完整保留历史）
1.5 课程目标与学习路径
本课程将带你从零构建一个基于 Go 语言、领域驱动设计（DDD）、事件驱动架构（EDA） 和 事件溯源（Event Sourcing） 的生产级 Web 系统。你将掌握：
- DDD 战术设计：聚合、实体、值对象、领域事件、仓储模式
- 事件驱动基础设施：Kafka / RabbitMQ 集成、事件序列化、幂等消费
- 事件溯源实现：事件存储、聚合重建、快照优化、并发控制
- Go 工程实践：项目结构、依赖注入、测试策略、性能调优
- 架构边界设计：限界上下文、事件版本管理、CQRS 分离
1.6 谁应该学习这门课程？
- Go 后端工程师：希望突破 CRUD 瓶颈，掌握高并发、高可用架构设计
- 架构师 / 技术负责人：正在评估或推行事件驱动 / DDD 在团队落地
- 微服务开发者：受够了分布式事务和同步调用链，想寻找更优雅的解决方案
- 技术创业者：需要构建一个可快速迭代、可审计、可扩展的业务系统
前置要求：熟悉 Go 语言基础语法和 HTTP 服务开发；了解基本的数据库和消息队列概念。不需要 DDD 或事件溯源经验，课程会从零开始讲解。