事件驱动（Event-Driven）

解决什么问题：微服务之间如何通信而不耦合—— 事件驱动 = 不可变事件流 + 异步消费 + 单写者 = 真正解耦。

核心方法论

事件驱动不是单一技术，而是一套完整的设计哲学，包含 6 个核心方法论：

1. 基础层

方法论	价值	解决
事件结构 3 类型	★★★★	不知道用什么结构的事件
单写者原则	★★★★★	多服务写同一聚合的冲突
Schema 演化 7 规则	★★★★★	事件 schema 改变导致消费者崩溃

2. 数据层

方法论	价值	解决
CDC 模式	★★★★	遗留数据库的事件化（避免应用双写）
状态物化	★★★★★	事件流到工作台的投影

3. 处理层

方法论	价值	解决
确定性流处理	★★★★★	可重放可测试的事件处理
流处理框架对比	★★★	重量级 vs 轻量级框架选择

4. 架构层

方法论	价值	解决
事件驱动工作流	★★★★	Choreography vs Orchestration 决策
事件+请求-响应混合架构	★★★★	纯事件驱动无法满足所有需求

5. 运营层

方法论	价值	解决
事件驱动下的可观测性	★★★★	异步系统看不到调用堆栈
事件驱动测试策略	★★★★	异步系统的测试金字塔

核心洞察

1. 事件流 = 单一事实源（SSOT）

传统架构：数据库是 SSOT
事件驱动：事件流是 SSOT（不可变）
         ↓
        数据库是事件流的物化（派生）

意义：事件流 = 时间序列信号 = 可重放、可恢复、可追溯。

2. 异步 + 持久 + 多次消费 = 真正解耦

特征：
  - 异步：发送者不等
  - 持久：消费后不销毁
  - 多次消费：新下游可加入
  
vs 同步 RPC：
  - 紧耦合（知道谁、为什么）
  - 级联失败
  - 难调试

3. 单写者 + CDC = 完美解耦

单写者：每个聚合只有一个服务写
CDC：DB binlog → 事件流
应用：只关心业务，不关心事件

避免应用层双写——这是分布式系统最大痛点。

4. Schema 演化 = 通信纪律

原则：Full Compatibility（双向兼容）
工具：Schema Registry + 代码生成
机制：升级前自动检查（fail-fast）

与 cybernetics 的对位

Event-Driven	工程控制论	L 层
事件流 = SSOT	Ch 15 测量的不可丢失	L3
Single Writer	Ch 6 §6.3 解耦	L1
Schema 演化	Ch 20 通信极限	L3
确定性流	Ch 4 §4.6 可重复	L3
Saga	Ch 6 §6.7 耦合利用	L2
Stateful Streaming	Ch 7 §7.5 非线性系统状态	L3
Workflow	Ch 21 多级分散协调	L2
事件观测	Ch 4 §4.6 反馈环路	L4
关联 ID	Ch 15 测量的"路径"	L4

与 IDDD 的对位

Event-Driven	IDDD	L 层
微服务 = 限界上下文	Ch 2 BC	L1
事件流 = 集成机制	Ch 13 集成	L2
单写者 = 聚合边界	Ch 10 聚合	L1
Saga = 跨 BC 一致性	Ch 8 事件	L2
Schema = Ubiquitous Language	Ch 2 通用语言	L1

阅读路径

入门：
  1. 事件结构 3 类型（核心概念）
  2. 单写者原则（边界纪律）
  3. Schema 演化 7 规则（通信纪律）

深入：
  4. 状态物化（核心机制）
  5. 确定性流处理（测试基础）
  6. CDC 模式（遗留系统集成）

架构：
  7. 事件驱动工作流（协调模式）
  8. 事件+请求-响应混合（实用架构）

运营：
  9. 事件驱动下的可观测性
  10. 事件驱动测试策略

与 themes/ 的对位

Event-Driven	业务主题
状态物化 + 关联 ID	observability
Saga + 补偿	data-consistency
工作流	architecture-evolution
Schema 演化	system-stability

状态

11 篇方法论全部升格完成（基于 Event-Driven Microservices Ch 2-15）。