我们有一个使用pub-sub模式实现的多步骤过程，我们正在考虑将Axon作为解决方案的主要部分。
简单来说，目标是为保险公司生成风险评分。这些步骤通常适用于发布订阅应用程序：
客户端通过将StartRiskScore消息放置在总线上并指定客户ID来开始该过程。客户端订阅RiskScorePart3消息以获取客户ID。
Actor A ，接收该消息，生成风险评分的第1部分，并将其作为RiskScorePart1消息（包括客户ID）放到总线上。
Actor B ，接收该消息，生成风险评分的第2部分，并将其作为RiskScorePart2消息（包括客户ID）放到总线上。
Actor C ，接收该消息，生成风险评分的第3部分，并将其作为RiskScorePart3消息（包括客户ID）放到总线上。
已为用户ID订阅RiskScorePart3消息的原始客户端收到消息，并且过程完成。
我考虑了以下Axon实现：
A。创建一个称为RiskScore
的聚合B。 StartRiskScore成为与RiskScore聚合关联的命令。
C。 StartRiskScore的命令处理程序将成为 Actor A 。它会处理一些数据，并在总线上放置一个RiskScorePart1事件。
现在，这是我关注的部分...
D。我会在一个单独的PubSub对象中创建RiskScorePart1事件处理程序，该事件处理程序除了使用事件中的数据在命令总线上放置CreateRiskScorePart2命令外，什么也不会做。
E。在RiskScore聚合中，CreateRiskScorePart2（ Actor B ）的命令处理程序将进行一些处理，然后将RiskScorePart2事件放在总线上。
F。与步骤D相似，RiskScorePart2的PubSub事件处理程序会将CreateRiskScorePart3命令放在命令总线上。
G。与步骤E相似，CreateRiskScorePart3（ Actor C ）的RiskScore聚合命令处理程序将进行一些处理，然后将RiskScorePart3事件放在总线上。
H。在聚合和RiskScoreProjection查询模块中，RiskScorePart3事件处理程序将分别更新聚合和投影。
I。通过对投影的预订查询来更新客户端。
我知道重新启动服务时会发生重播。这对旧事件不利，因为我不想重新触发来自PubSub处理程序的命令。对于在PubSub服务关闭时发生的新事件来说，这是个好消息。
编辑＃1：
我考虑过使用Axon传奇，这太好了。但是，即使PubSub是一个传奇，同样的问题仍然存在：
即使在重新启动后，如何确保PubSub事件处理程序也仅一次处理每个事件？
我应该采用其他方法在Axon中实现发布订阅模式吗？
感谢您的帮助！
答案 0 :(得分：0)
我想我可以在这方面提供一些指导。
在您的更新中，您已指出您设想使用Saga来执行此设置。
但是，我想指出的是，“传奇”旨在“在有界的上下文/聚合之间编排复杂的业务交易”。您所描述的场景不是其他上下文和/或聚合之间的事务，而是全部包含在单个聚合根RiskScore中。
因此，我建议您不要在这种情况下使用Saga，因为该工具（阅读：Saga）相对来说要等您描述的内容。
第二，从您描述的步骤中，从 A 到 I ，看起来步骤 D 和 F 纯粹是在现场对事件做出反应。因此，按照这种假设，他们执行零业务功能。
以单个聚合根中包含的事务的初始点为基础，并且 实际上，在将命令分派回聚合中时，没有业务功能发生，为什么不包含整个操作在RiskScore聚合中？
您可以非常轻松地处理聚合通过@EventSourcingHandler发布的事件，并在该方法上应用另一个事件。或者，如果您想“纯粹”分离状态更新并应用事件，则可以在此之后为单独的风险评分步骤应用更多事件。
无论如何，我不明白为什么您需要紧紧抓住pub-sub模式。我将采用一种解决方案，以尽可能最佳地解决业务需求。那可能是一个现有的模式，但也可能是您可以考虑的任何其他方法。
这是我对情况的两分钱，希望他们能帮忙！