architecture-paradigm-cqrs-es

CQRS 与事件溯源范式

适用场景

• 设计具有复杂领域逻辑的事件溯源系统
• 需要完整状态变更审计轨迹的系统

不适用场景

• 没有复杂领域逻辑的简单 CRUD 应用
• 事件溯源会带来不必要复杂性的小型项目

何时采用此范式

• 读写负载的性能特征或扩展需求差异巨大时。
• 所有业务事件都必须记录在持久、不可变的历史记录或审计轨迹中时。
• 业务需要重建数据投影或支持时间查询（例如：“昨天这个实体的状态是什么样的？”）时。

采用步骤

1. 识别聚合：遵循领域驱动设计原则，明确限界上下文，以及每条命令必须在聚合上强制执行的业务不变量。
2. 为命令和事件建模：定义所有命令的架构和验证规则，以及这些命令生成的事件。记录清晰的版本管理和架构演进策略。
3. 实现写入端（命令端）：命令处理程序负责加载聚合的事件流、执行业务逻辑，并以原子方式向流中追加新事件。
4. 构建读端投影：创建由事件流订阅提供数据的独立读取模型（投影）。为这些订阅实现背压和重试策略。
5. 验证完整的可观测性：实现详细日志记录，其中包含事件 ID、序列号，以及用于跟踪每个投影滞后时间的指标。

关键交付成果

• 一份架构决策记录（ADR），详细说明聚合、选定的事件存储技术、投影策略，以及预期的数据一致性模型（例如，最终一致性 SLA）。
• 一套使用内存事件流的命令处理程序测试，并辅以投影集成测试。
• 用于重放事件、为提升性能创建状态快照以及管理架构迁移的运维工具。

风险与缓解措施

• 较高的运维开销：
  • 缓解措施：与事件排序和重放相关的错误可能很难诊断。应大力投入自动化，为失败事件设置死信队列（DLQ），并定期开展“混沌工程”演练以测试韧性。
• 最终一致性的挑战：
  • 缓解措施：用户可能会因执行操作后需要等待才能看到结果而感到困惑。应明确记录读取模型更新的 SLA，并妥善管理用户预期，例如在命令端提供即时反馈。
• 架构漂移：
  • 缓解措施：计划外更改事件架构可能会导致消费者失效。应强制使用正式的架构注册表，并在 CI/CD 流水线中实施版本门禁，以防止发出未经验证的事件版本。

具体组件

此范式的实现通常会包含的工具和抽象的词汇表。它们不是依赖项，也不是 tools: 前置元数据。

• event-store：仅追加的领域事件日志；系统的事实来源，投影由此构建
• message-broker：在限界上下文之间传递命令和集成事件
• projection-builder：通过重放事件存储来重建读端视图

退出标准

• 已编写 ADR，明确列出聚合、选定的事件存储技术、投影策略，以及每个读取模型的最终一致性 SLA。
• 命令处理程序测试使用内存事件流，并在接入任何持久化适配器之前通过。
• 已记录事件架构的注册表或版本管理策略，且 CI 门禁会阻止发出该策略中未注册的事件版本。
• 在宣布写入端已可投入生产之前，已确定（而非仅仅提及）用于事件重放和状态快照的运维工具。