问流程管理器如何跟踪聚合之间的关联？

EN

强烈推荐通过过程管理器设计模式的原始来源，以及@ Vernon在他的伟大著作“实现领域驱动设计”中对这个主题的处理

简而言之，processes通过它在启动特定进程时创建的流程实例并发处理多个进程。流程实例的Id是您的相关标识符，它是进程持续时间内每个通信的有效负载(命令/事件)的一部分。流程实例还有另一个术语，即流程跟踪器。想法是一样的。

因此，在这种方法中，有一个明确的分离关注。每个进程实例根据其当前状态、重试、完成等来负责它自己的进程，它是一个进程实例，它负责发出ProcessFinished事件，因为它是“大脑”。

流程管理器的另一个名称是长时间运行的流程。因此，从定义上来说，最好是异步的。

~ Sergiy

<><

我认为过程经理是我领域内的头等公民。流程管理器实例的Id通常充当相关Id。由于流程管理器是一个状态机，它实际上可以发布事件。我认为领域事件不同于系统事件。消息传递基础结构依赖于系统事件。它们将携带相关id，是的，它将被复制到相关消息，但这是您的基础设施可以自动完成的事情。在我的Shuttle.Esb服务总线中，我只做了这样的工作:复制标头和关联id。

这就是为什么我也把事情的过程方面看作是BC本身的一种类型。它通过发出命令，然后响应相关事件，与构成进程一部分的各种BCs进行交互。但是在基础结构(端点)层上，我可能希望发布一个事件，该事件声明某个特定进程已经放弃、完成或从一个步骤转移到下一个步骤。

编辑

在我看来，流程管理器本身也是一个集合。所有命令和事件都将来自消息处理程序/应用程序层，以响应域中发生的事情。任何来自域的事件，从本质上来说，都是域事件，这些事件不一定适合系统到系统通信。我认为“在集成/应用程序层上”比在基础结构(端点)层上更合适。

所有消息都在消息处理程序中处理。该消息处理程序充当集成点，必须直接或通过应用程序层与域交互。我的措辞可能没有说明这一点:)

免责声明:由于您提到的示例使用了"saga“和”过程管理器“两个术语，所以我也会这样做。我知道saga和流程管理器模式在定义上是不同的，但是在行业中，我们看到saga这个词正在被许多流行的框架所应用(从NServiceBus开始)。

考虑到这个特定的例子，它将是：

• 发布传奇事件:视情况而定。我强烈警告你不要对谁能做什么建立任何教条主义的方法。你永远不可能知道第二天会带来什么，你不应该“按书”做任何事情。如果ProcessManager编排了整个流程，它很可能会从一个聚合或上下文中使用OrderConfirmed事件，将命令发送到下一步，等待它生成确认事件，并在整个过程完成时发出它自己的事件，在这种情况下，它通过一些UI魔术发送给客户。我看不出这种做法有什么不对。不过，也许有更好的解决办法。
• 通常情况下，saga id ==相关性id和它要么是人为的短生命标识，在这种情况下，您确实需要跟踪相关，或者依赖您的基础设施将它从命令传递到命令处理程序端的事件。一旦创建了saga实例，您就需要生成这样的id (记住，saga具有逻辑和状态，每个正在运行的进程都有自己的状态)。或者您可以使用某些域对象id，例如在您所引用的情况下，这可能是order id。尽管如此，您仍然需要小心地将相关id从命令传递到命令处理程序端的事件。因此，saga id ==相关id ==进程状态id，也常被用作saga状态持久化的主要密钥。

您还可以找到一篇关于使用状态机和MassTransit框架在克里斯·帕特森的博客文章中长期运行的流程实现的很好的博客文章。