与事件源（CQRS）进行微服务交互的最佳实践

Question

我有一个API调用，它将需要使用多个聚合。我想到了以下两个想法如何与聚合进行交互，但是我对其他想法持开放态度。

从一种微服务向另一种微服务发送命令是一种好习惯吗？还是在微服务B上设置事件处理程序来对服务A的事件做出反应并在微服务B内全部生成命令更好？

Answer 1

  

从一种微服务向另一种微服务发送命令是一种好习惯吗？还是在微服务B上设置事件处理程序来对服务A的事件做出反应并在微服务B内全部生成命令更好？

在服务体系结构中要认识的重要一件事：我们希望服务是自治的。因此，A应该在B停止维护时继续工作，反之亦然。

这意味着我们需要支持从A到B的异步消息传递。

当前的“最佳实践”是您正在处理异步传递的消息，然后语义应该是过去时：SomethingHappened处的A，B将对此作出反应，是否自行决定。

有关系吗？很难说-handle(Event)是命令，CommandReceived是事件。

注意：这实际上只是服务和消息传递-事件源/ CQRS确实不参与其中。

马丁·福勒（Martin Fowler）在2005年描述了Domain Events。

  

每个域事件都从外部刺激中捕获信息。

如果您认为A是B的外部（这是有道理的，如果它们之间存在服务边界），则域事件模式的语义可能非常适合。

Answer 2

为什么不是两个？

我对这些“微服务”的处理略有不同。对于每个有界上下文，我通常都有一个消息传递终结点。我想这很符合微服务的想法，并且 端点仅响应发送给它的，适用于该BC的命令。然后还将发布相关事件。

然后我可能还拥有一个业务流程端点，该端点响应“属于”相关BC的流程管理器。该端点仅处理过程管理器的状态，并向与之对话的任何BC消息传递端点发出命令。例如，在已经收到OrderRegisteredEvent之后，可以发布SendEMailCommand。好的，那更多的是技术端点/ BC，但仍然如此。

在仅BC的消息传递终结点上，不同BC之间绝对没有 否 。在那里唯一为自己的BC服务。

我希望这是有道理的。