基于CQRS、EDA的微服务：跨限界上下文的事件消费API选型

在CQRS架构的微服务系统里，通过事件总线跨上下文消费事件时，既不该用Command API也不该用Query API，正确的做法是给每个限界上下文单独实现事件处理器组件，直接对接事件总线处理外部事件。

为什么不能用Command API？ #

• 语义不匹配：Command的本质是“请求做某事”，是主动发起的指令；而消费事件是“响应已经发生的事实”，是被动触发的逻辑。硬把事件塞给Command API，会混淆业务逻辑的发起方和响应方，让代码可读性变差。
• 模式冲突：Command API一般是同步请求-响应模式，而事件消费通常是异步、批量、需要重试的场景，强行适配会增加不必要的复杂度，比如要处理同步接口的超时、重试逻辑，完全没必要。
• 职责混乱：Command API的职责是接收外部业务指令并触发状态变更，事件消费是同步外部上下文的状态或更新本地视图，两者职责完全不同，混在一起会违反单一职责原则。

为什么不能用Query API？ #

• 能力不匹配：Query API的核心是提供只读数据查询，没有修改本地状态或更新视图的权限和能力。但消费跨上下文事件大多需要做状态更新（比如用户上下文消费积分到账事件更新用户积分），Query API根本做不了这事。
• 设计目标不符：Query API是为了高效处理外部查询请求优化的，比如缓存、分页、聚合等，和事件消费的异步、顺序处理需求完全不搭，强行用会导致性能问题。

正确实践的优势 #

• 职责清晰：事件处理器专门负责对接事件总线，处理外部事件的逻辑，和Command、Query的职责彻底分离，代码更容易维护。
• 灵活可控：可以独立配置事件消费的重试策略、幂等处理、异步线程池，不会影响Command/Query API的稳定性和性能。
• 扩展方便：新增事件类型时，只需要新增对应的事件处理器类，不需要修改已有的Command/Query接口，符合开闭原则。

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