CQRS结合Event Sourcing时命令持久化逻辑：两种方案哪个正确？

要理清这个问题，得先明确CQRS+Event Sourcing（以下简称ES）的核心设计原则：事件是唯一的事实来源，所有业务状态都应该通过重放事件来构建，而非直接写入状态存储。

先分析你提到的两种方案：

方案1的问题 #

方案1里命令侧直接写入主数据库再分发事件，本质上只是用事件做后续异步联动，并没有真正落地ES。这种模式更像是「CQRS+事件驱动」，而非CQRS+ES——主数据库仍然是业务状态的权威来源，事件仅作为通知手段，完全违背了ES「以事件为中心」的核心，也浪费了ES带来的可追溯、状态重建等核心优势。

方案2才是符合CQRS+ES原则的正确方案 #

方案2的思路完全契合ES的设计逻辑，具体分工如下：

• 命令侧：仅负责验证命令合法性（比如检查用户名是否重复、参数是否合规），验证通过后生成并持久化UserCreated事件（这里的持久化是写入事件存储，而非业务数据库）。命令侧不直接操作任何业务状态存储。
• 事件侧：通过不同的事件处理器（投影器）处理UserCreated事件，完成所有后续操作：
  • 投影处理器1：重放事件构建用户状态，写入关系型主数据库（供结账等业务查询使用）
  • 投影处理器2：将用户数据同步到ElasticSearch
  • 投影处理器3：完成CRM系统的用户导入
  • 投影处理器4：发送注册成功通知

这里的关键是：事件存储是唯一的权威数据源，主数据库、ElasticSearch、CRM都是派生视图，它们的状态完全由事件投影生成。这样做不仅符合ES原则，还能享受ES带来的全链路可追溯、状态回溯、系统容错等好处。

补充说明 #

很多博客或库的方案1，其实是为了降低落地门槛——让团队在不彻底改造现有状态存储的前提下，先用事件驱动实现部分CQRS的优势。但如果你的目标是严格遵循CQRS+ES的设计，方案2是唯一正确的选择。

内容的提问来源于stack exchange，提问作者itinance