轴突指令的分离及其作用

Question

我在维护一个事件源的应用程序，恐怕它已经走得很远了。

1. 将命令(cmd1)发送到另一个聚合根，该聚合根将发布一个事件，该事件将创建许多传奇，每次触发一些最终由许多聚合处理的命令
2. 发送第二个命令(cmd2)，该命令也将导致各种命令/事件/命令序列。

以示意图的形式：

cmd0 -> AR0 -> evt0 -> evtHandler -> cmd1 -> AR1 -> evt1 -> saga stuff and more cmds and evts
                                 |-> cmd2 -> AR2 -> evt2 -> more saga stuff, cmds and evts

所有事情都发生在同一个线程中，所有事情都发生在第一个命令处理开始的1个事务中。

Answer 1

老实说，Jan，最好是应用程序中的组件不太依赖于该顺序。它本质上意味着您有不同的消息处理组件，这些组件本质上可以是不同的微服务，但它们都绑在一起，因为顺序很重要。

理想情况下，您应该将组件设置为独立工作。因此，聚合处理命令并发布结果，完成。传奇对事件做出反应，不管它们来自哪里，并通过行动对其做出反应（例如命令调度）。

在这里，接受可能性会有所帮助，因为它将放弃等待一个过程完成的全部要求。

关键是所有的影响是什么。从分派该命令开始，您应该只关心该命令是否成功地处理yes或no，这才是问题的终点。

我知道这不会给你一个简单的编程解决方案，因为你需要调整设计。但我认为脱钩是唯一正确的方式去听。

这是我对这种情况的两分钱，希望这有助于你在任何方面更进一步。

• 命令-命令始终被路由到单个实例上的单个句柄。此外，您还可以预期OK或NOK形式的响应。OK的意思是处理程序是void或创建的实体的标识符（就像聚合本身一样）。NOK通常是从命令处理方法中抛出的异常，它表示出了问题，或者命令无法执行，应该通知调度端。
• events-事件将广播给任何订阅eventbus并能够处理给定事件的组件。请注意，事件处理在时间上与事件的实际发布点分开。这意味着无法将事件处理的结果返回给事件的调度程序。
• 查询-查询消息可以以多种形式路由。单个组件最适合回答查询（称为点对点查询）。您还可以将查询分派给多个处理程序并聚合结果（称为分散-聚集查询）。最后，您可以通过执行“订阅查询”来订阅查询模型，该查询本质上是由更新流跟踪的点对点更新的组合。显然，查询分派意味着您正在接收来自某个组件的结果。只是在查询类型上有自由。如果需要任何关于查询响应的“最新”的保证，那么应该将其作为所发送查询的实现以及@queryhandler注释方法如何处理查询响应的一部分。

希望这为Axon应用程序中的每个消息提供了一些额外的清晰度！