发布 / 订阅（基线方案）
使用场景: 构建首个事件驱动系统的开发者
生产者发布到主题，broker 扇出给订阅者
无事件存储——事件被处理后即遗忘
每个消费者维护自己的偏移 / 位置
至少一次投递；消费者处理重复
示例：Kafka 主题、RabbitMQ 交换机、AWS SNS
这样组织的原因: 发布 / 订阅是最清晰的起步模式——事件从生产者到订阅者只流一次、不保留。图表没有事件存储，因为现阶段不需要重新处理。
真实案例
事件溯源
使用场景: 事件日志即真相来源的团队
每次状态变化都记录为不可变事件
通过重放事件派生出当前状态
事件存储是系统记录，而非副作用
新消费者可从头重放重建状态
审计和时间旅行查询变得平凡
这样组织的原因: 事件溯源让事件日志成为权威——图表把事件存储放在中心，因为状态由它派生、而非存在各服务数据库里。新增视图意味着写一个新消费者重放历史。
服务编排式协作
使用场景: 无中央编排器协调微服务的团队
无中央协调者——服务对彼此的事件做出反应
下单 → 库存预扣 → 支付授权 → 物流预订
每一步发出下一服务订阅的事件
更易扩展、更难端到端追踪
补偿事件处理失败（Saga 模式）
这样组织的原因: 编排式协作让服务对彼此事件反应，无需中央编排器——图表展示一连串生产者-消费者关系，每个服务身兼两角，扩展性好但比中央编排更难追踪。
带事件投影的 CQRS
使用场景: 分离读写模型的团队
写侧：命令产生事件进入总线
事件投影到一个或多个读模型
读模型按查询优化（搜索、看板、API）
写读之间最终一致
通过重放事件可重建读模型
这样组织的原因: 带投影的 CQRS 天生事件驱动——图表把写侧事件日志与多个读侧投影配对，让每个查询得到按其访问模式定制的去规范化视图。
使用技巧
- 把事件总线画成独立节点而非一条线——它是一个带自身扩展和失败模式的部署组件。
- 在箭头上标注主题或事件类型；说「事件流动」却不命名等于掩盖真正的契约。
- 如果需要重放，把事件存储与总线分开；某些 broker（Kafka）兼任两者，但图表应明确哪个保存历史。
- 在视觉上区分生产者和消费者；许多服务两者都做，但在某个事件流中只扮演一角。
在线开始编辑
回到模板页，直接替换成你的课程主题、章节和复习重点，就可以继续使用这套结构。
使用这个模板： /editor/new?template=event-driven-architecture
编辑此事件驱动模板