我有一个API调用，需要使用多个聚合。我头脑中有两个想法，它应该如何与聚合进行交互，但我对其他想法持开放态度。
将命令从一个微服务发送到另一个微服务是一种好习惯吗？或者，在微服务B上有一个事件处理程序对服务A的事件作出反应并在微服务B中生成所有命令更好吗？
将命令从一个微服务发送到另一个微服务是一种好习惯吗？或者，在微服务B上有一个事件处理程序对服务A的事件作出反应并在微服务B中生成所有命令更好吗？
在服务架构中要认识到的一件重要事情：我们希望服务是自治的。所以A应继续工作，而B停止维护，反之亦然。
这意味着我们需要支持从A到B的异步消息传递。
当前的“最佳实践”是你正在处理异步传递的消息，然后语义应该过时：SomethingHappened上的A，B会根据自己的判断在自己的时间内对它作出反应。
有关系吗？很难说 - handle(Event)是一个命令，CommandReceived是一个事件。
注意：这实际上只是服务和消息传递 - Event-Sourcing / CQRS确实没有进入它。
Martin Fowler在2005年描述了Domain Events。
每个域事件都捕获来自外部刺激的信息。
如果你认为A是B的外部（这是有意义的，如果它们之间存在服务边界），那么域事件模式的语义可能非常合适。
为什么不兼得？
我对这些“微服务”的看法略有不同。我通常为每个有界上下文都有一个消息传递端点。我想这与微服务理念非常吻合，并且该端点仅响应发送给它的适用于该BC的命令。然后它还会发布相关事件。
我当时可能还有一个编排端点，它响应“属于”相关BC的流程管理器。此端点仅处理流程管理器的状态，并向需要与之交谈的BC消息传递端点发出命令。例如，在收到OrderRegisteredEvent后，可能会签发SendEMailCommand。好吧，这更像是一个技术终点/ BC，但不是更少。
在仅BC的消息传递端点上，不同的BC之间绝对没有。它只是服务自己的BC。
我希望这是有道理的。