E1 - 入门：为什么事件驱动微服务
事件驱动微服务解决什么？什么时候用？什么时候不用？——回答"我应不应该采用事件驱动架构"的入门章。
一句话
事件驱动微服务 = 用异步事件流作为单一事实源（SSOT），微服务从流中物化状态的分布式架构。通信媒介决定耦合度（McLuhan）+ 业务通信结构决定实现通信结构（Conway）。
这本书在这一层说了什么
本层基于 EDM Ch 1 完整精读（42KB / 6329 词）。
Bellemare Ch 1 开篇 McLuhan 引言：
"The medium is the message."
Bellemare 关键洞察：
"The medium of the asynchronously produced and consumed event has been fundamentally shifted by modern technology. These events can now be persisted indefinitely, at extremely large scale, and be consumed by any service as many times as necessary."
核心论点 4 个：
- What Are Event-Driven Microservices — 事件驱动微服务是什么
- Introduction to DDD and Bounded Contexts — DDD 4 大概念融合
- Leveraging Domain Models and Bounded Contexts — 如何对齐业务与实现
- Aligning BCs with Business Requirements — BC 边界对齐业务变化
是什么
1. McLuhan 媒介论（The Medium is the Message）
Bellemare 原话：
"You need only look at the history of computing inventions to see how network communications, relational databases, big-data developments, and cloud computing have significantly altered how architectures are built and how work is performed."
核心论点：媒介本身比内容更重要——架构不仅由功能决定，更由通信媒介决定。
| 媒介 | 对架构的影响 |
|---|---|
| 数据库 | 单点真理 → 紧耦合 |
| 网络（同步） | 分布式通信 → 解耦可能 |
| 事件流 | 异步 + 持久 + 多消费 → 真正解耦 |
Bellemare 关键论断：
"These events can now be persisted indefinitely, at extremely large scale, and be consumed by any service as many times as necessary."
根本区别：事件流是"可重放的持久事实"，数据库是"当前状态"。事件流保留了变化过程。
2. 事件驱动微服务 vs 传统 SOA
Bellemare 关键区分：
SOA（Service-Oriented Architecture）：
- 微服务同步调用
- 紧耦合
- 失败级联
事件驱动微服务：
- 异步消费/生产
- 事件持久化（消费后不销毁）
- 真正解耦Bellemare 关键论断：
"In a modern event-driven microservices architecture, systems communicate by issuing and consuming events. These events are not destroyed upon consumption as in message-passing systems, but instead remain readily available for other consumers to read as they require. This is an important distinction, as it allows for the truly powerful patterns covered in this book."
3. 微服务的"小"如何定义？
Bellemare 两种定义：
定义 1：2 周写完（具体度量）
定义 2：能在一个人脑子里装下（认知度量）Bellemare 论断：
"A typical definition of 'small' is something that takes no more than two weeks to write. By another definition, the service should be able to (conceptually) fit within one's own head."
4. 微服务的形态
Bellemare 列举：
- 长跑独立应用（Stateful / Stateless）
- Functions-as-a-Service（FaaS）
关键：微服务的形态多样，但核心都是消费/生产事件。
5. DDD 4 大概念（与 IDDD 融合）
Bellemare 在 EDM Ch 1 引入 DDD，与 IDDD 完美对位：
| 概念 | Bellemare 定义 |
|---|---|
| Domain | "The problem space that a business occupies and provides solutions to." |
| Subdomain | "A component of the main domain... A subdomain can be seen as a domain in its own right." |
| Domain Model | "An abstraction of the actual domain useful for business purposes... part of the solution space." |
| Bounded Context | "The logical boundaries, including the inputs, outputs, events, requirements, processes, and data models, relevant to the subdomain... part of the solution space." |
Bellemare 关键对位：
"Bounded contexts should be highly cohesive. The internal operations of the context should be intensive and closely related, with the vast majority of communication occurring internally rather than cross-boundary."
"Connections between bounded contexts should be loosely coupled, as changes made within one bounded context should minimize or eliminate the impact on neighboring contexts."
两个关键原则：
- 高内聚（High Cohesion）= 内部操作紧密相关，大部分通信内部发生
- 松耦合（Loose Coupling）= 跨 BC 变更影响最小化
6. Subdomain → BC → Microservice 映射
Bellemare 映射流程：
1. 业务分解为 Subdomain（业务空间）
2. Subdomain → Bounded Context（解决方案空间）
3. BC → Microservice（物理实现）Bellemare 关键论断：
"Bounded contexts are established around these subdomains and form the basis for the creation of microservices."
映射不总是 1:1：
"While ideally a bounded context and a subdomain will be in complete alignment, legacy systems, technical debt, and third-party integrations often create exceptions."
7. Conway 定律 + 通信结构
3 大通信结构（本层融合 DDD）：
业务通信结构（Business Communication Structure）：
= 组织结构 + 业务流
实现通信结构（Implementation Communication Structure）：
= 微服务如何通信
数据通信结构（Data Communication Structure）：
= 数据如何流动Bellemare 关键论断：
"It is common for the business requirements of a product to change during its lifetime, perhaps due to organizational changes or new feature requests. In contrast, it's rare for a company to need to change the implementation of an established microservice."
洞察：业务变化频繁，实现变化少——BC 必须对齐业务而非技术。
为什么
为什么通信媒介决定耦合度？
根因：通信媒介的"共享程度"决定耦合度。
| 共享程度 | 耦合度 |
|---|---|
| 数据库共享 | 紧耦合（共享 schema） |
| HTTP 同步 | 中耦合（接口契约） |
| 事件流异步 | 弱耦合（事件 schema + 自描述） |
Bellemare 关键论断：
"The medium of the asynchronously produced and consumed event has been fundamentally shifted by modern technology."
根因 1：事件持久 → 新消费者可重放历史 → 不破坏现有消费者 根因 2：异步 → 失败不级联 → 解耦消费者 根因 3：多消费者 → 业务变化只需添加消费者而非修改生产者
为什么事件持久化是关键？
Bellemare 关键区分：
消息队列（RabbitMQ 默认）：
消费即销毁 → 消息只活 1 次
新增消费者需要"重放"历史数据 → 状态丢失
事件流（Kafka）：
持久 + 多消费者 → 任意时间点可消费任意分区
新增消费者无需"重放" → 状态可重放可重建根本区别：消息队列是"通知"语义；事件流是"事实"语义。
为什么 BC 必须高内聚松耦合？
Bellemare 论断：
"Bounded contexts should be highly cohesive... Connections between bounded contexts should be loosely coupled."
高内聚：
- 减少设计范围
- 简化实现
- 内部演化不影响外部
松耦合：
- 变更隔离
- 一个 BC 的需求变化不传播到邻居
怎么做
Step 1：评估"是否事件驱动"
决策矩阵：
Q1: 业务事件需要多个消费者吗？
是 → 事件驱动候选
否 → 同步 API 够用
Q2: 业务事件需要追溯历史吗？
是 → 事件驱动（事件流 = SSOT）
否 → 数据库够用
Q3: 业务变化频繁 + 团队规模大？
是 → 事件驱动 + 微服务
否 → 单体可能更合适Step 2：识别业务通信结构
方法：
1. 画组织结构图（团队边界）
2. 画业务事件流图（业务事件如何流动）
3. 比对：业务事件流是否被组织边界阻塞？
→ 阻塞 = BC 边界错位
→ 顺畅 = BC 边界合理Step 3：建立 Subdomain → BC 映射
流程：
1. 业务空间分析（Subdomain 划分）
2. 解决方案空间分析（BC 划分）
3. 物理实现（微服务）
4. 验证：业务变化时 BC 是否跟着变Step 4：渐进迁移到事件驱动
迁移路径：
阶段 1：单体内部发事件（事件总线 / 进程内）
阶段 2：单体与新服务通过事件通信
阶段 3：拆分为事件驱动微服务
阶段 4：完全事件驱动 + 事件溯源什么时候用 / 什么时候不用
用事件驱动微服务的 2 大场景
| 场景 | 关键判断 |
|---|---|
| 跨服务业务事实需要可靠传递 | 业务事件不止一个消费者，且需追溯 |
| 业务需要解耦团队独立演化 | 多个团队各自负责 BC，且 BC 频繁变更 |
不用事件驱动微服务的 4 大场景
| 场景 | 原因 | 替代方案 |
|---|---|---|
| 单体足够的小系统 | 微服务税 > 收益 | 单体 + 模块化 |
| 强一致 + 低延迟（如交易撮合） | 事件最终一致延迟不满足 | 同步 RPC + 强一致数据库 |
| 极简 CRUD + 单团队 | 复杂度过剩 | REST + 数据库 |
| 客户端直连 + 实时双向 | 事件单向 + 持久不适合 | WebSocket / gRPC stream |
看不见的地方
失效模式 1：以为"用 Kafka 就是事件驱动"
症状：团队用 Kafka 但业务逻辑仍是同步思维 → 失败级联、数据漂移。
根因：Kafka 是工具，不是架构。事件驱动需要"事件优先 + 异步 + 持久"的思维。
修复：先改思维（业务事件 = 事实），再选工具。
失效模式 2：Conway 定律违反
症状：1 个团队维护 5 个微服务 → 团队过载 → 变更慢。
根因：架构与组织不匹配——Conway 定律反向生效。
修复：要么合并微服务（与组织对齐），要么拆团队（与架构对齐）。
失效模式 3：把消息队列当事件流
症状：用 RabbitMQ 默认队列做事件流 → 新增消费者失败 → 历史数据无法重放。
根因：RabbitMQ 默认行为是"消费即销毁"，不是"持久可重放"。
修复：换 Kafka / Pulsar，或开启 RabbitMQ Streams 插件。
失效模式 4：BC 边界按技术层划分
症状：BC 边界 = 数据库表 / 包名 / 模块 → 后期业务变更必须跨 BC。
根因：未基于业务能力划分。
修复：BC 边界对齐业务能力变化（业务变化时 BC 才变化）。
失效模式 5：业务变化频繁 → 微服务税爆炸
症状：5 个微服务 + 3 个团队 + 单一业务领域 → 协调成本 > 收益。
根因：过早微服务化。
修复：先单体 + 模块化，到 50+ 开发者或 BC 边界清晰时再拆。
相关节点
骨架 A — 世界观
| 节点 | 关联 | 解释 |
|---|---|---|
| wonder-01-emergence-vision | 强 | 事件流 = "涌现视域"——所有业务事件构成整体的涌现视域 |
| wonder-04-encounter | 中 | 事件 = BC 间 "照面"载体——通过事件照面彼此 |
骨架 B — 工程实践
| 节点 | 关联 | 解释 |
|---|---|---|
| change-management | 中 | 事件驱动 = 渐进迁移——分阶段切换通信媒介 |
与 IDDD L1 对位
| IDDD L1 | EDM E1 |
|---|---|
| DDD 是协作方法论 | 事件驱动是通信媒介选择 |
| Ubiquitous Language | McLuhan 媒介论（语言即通信媒介） |
| 何时用 DDD | 何时用事件驱动 |
与海德格尔对位
Bellemare 的"事件流 = SSOT" = 海德格尔的"世界之为世界"：
- 海德格尔：世界不是对象的集合，而是"让对象显现的视域"
- Bellemare：事件流不是事件的集合，而是"让业务事实可重放的媒介"
- 两者都是"在某个整体中，每个元素才有意义"
状态
E1 概念递进落地完成（基于原书 ch01 42KB / 6329 词）。
- 4 个核心论点（McLuhan / 事件驱动 vs SOA / 微服务定义 / DDD 融合 / Conway）
- 6 个失效模式
- 骨架 A/B + IDDD + 海德格尔完整映射