事件驱动架构中的响应

Question

经典的EDA示例涉及一个命令触发事件——就像多米诺骨牌一样。

PlaceOrder->OrderPlaced→PaymentSucceeded→OrderShipped

通常，Order Service在此过程中监听事件以保持订单状态的更新。可能是(这是每篇文章都跳过的部分!)，因为在某些时候，订单服务将接收到ViewOrder命令，这将需要一个超出"ok"的响应。

所以我的问题是:在EDA中，至少有一些服务必须对事件和

命令做出反应吗?如果不是，什么架构可以分隔"命令世界"?(需要支持HTTP API)从"事件世界";执行异步处理的服务?

Answer 1

根据我的经验，我们构建的每个微服务都做到了这两件事。参与消息传递平面(发布和/或订阅)始终是一项需求，并且在大多数情况下，至少公开一个API端点也是一项需求。事实上，我不相信我们有任何不公开API端点的活动服务，尽管我们有一些可能这样做。

到目前为止，我们还没有遇到将服务分成单独的API服务和事件总线交互部分有价值的情况。我不是说这是不可能的，但我们非常关注封装(功能)域的服务，而不太关心实现。这使我们能够使用一种非常公式化的方法来创建服务本身，这也是我们选择这种架构风格的一个重要原因。