从Eventuate中的多个事件日志中读取

Question

我正在玩一些活动采购的东西，以便感受它。我想要尝试的下一件事是Eventuate。它看起来非常好，但是根据我从文档中收集的内容，任何EventsourcedActor（以及View，Processor变体等）只能读取和写入单个事件日志。

例如，我有一个User事件日志，系统的每个用户都有EventsourcedActor个。这些将获得CreateUser，ChangePassword或DeleteUser等命令，并发出UserCreated等事件。

现在假设这是一个论坛应用程序，一旦用户删除了他们的帐户，该用户的现有帖子应该被删除或以其他方式标记。

我该怎么做？我本能地为论坛帖子/帖子提供一个单独的事件日志，但在这种情况下，我不知道处理这些事件的演员如何能够听取像UserDeleted这样的事件。

我是否真的需要为整个应用程序提供一个巨大的事件日志？或者我可以让演员从多个事件日志中读取吗？

我看过EventsourcedProcessor可以从一个事件日志中读取并写入另一个事件日志。使用它作为桥接器似乎有点奇怪。只是为了从一个日志到另一个日志获取事件。

我想要的是让任何给定论坛帖子的聚合/演员听一个UserDeleted事件，然后相应地修改它的状态。

但鉴于这一切，我不确定我是否在这里完全走错路。

Answer 1

鉴于Users事件日志和ForumPosts事件日志，使用EventsourcedProcessor消耗来自UserDeleted事件的Users事件实际上是合理的记录并将它们（可选地转换）写入ForumPosts事件日志。

每当代表用户论坛帖子的EventsourcedActor被激活时，他们就会使用UserDeleted事件，并将其内部状态更改为已删除。与previous answer中描述的流程管理器方法相比，它具有以下优势：论坛帖子演员不需要处于活动状态来处理来自流程管理器的命令，这对您来说尤其有用拥有数千或数百万这些演员。使用event-driven communication，您可以及时解除分离。

如果您仍想遵循流程管理器方法，可以使用confirmed delivery向接收方可靠地提供流程管理器命令，并结合论坛帖子命令处理程序中的幂等命令处理演员。另一方面，通过事件驱动的通信，如前一段所述，您不需要关心事件处理程序中的幂等性，因为EventsourcedProcessor是幂等生成者，即您永远不会看到{{{ 1}}在UserDeleted事件日志中重复。

Answer 2

  

它看起来非常好，但是根据我从文档中收集的内容，任何EventsourcedActor（以及View，Processor变体等）只能读取和写入单个事件日志。

听起来每个EventsourcedActor都应该是一个Aggregate。这很合理。

  

现在假设这是一个论坛应用程序，一旦用户删除了他们的帐户，该用户的现有帖子应该被删除或以其他方式标记。

     

我该怎么做？我会本能地为论坛帖子/帖子提供一个单独的事件日志，但在这种情况下，我不会看到处理这些事件的演员如何能够监听像UserDeleted这样的事件。

     

我是否真的需要为整个应用程序提供一个巨大的事件日志？或者我可以让演员从多个事件日志中读取吗？

通常的习惯用法是＆＃34;流程管理员＆＃34;的名称。基本思想是你有一个非常简单的事件处理程序，用于监听EventsourcedActors所写的更改。当UserDeleted事件出现时，进程管理器通过将ArchivePost命令发送到维护帖子历史记录的EventsourcedActors来响应。

基本上，流程经理是美化的状态机; ＆＃34;当我看到事件A，B和C时，我应该安排命令D＆＃34;。在我看到的示例中，调度是异步的 - 也就是说，它运行在与事件处理程序不同的线程上。

更改模型的所有责任;也就是说，维护记录簿完整性的责任属于EventsourcedActors。协调这些变化 - 确保将正确的命令发送给正确的参与者，这是状态机所做的事情。

上述所有内容都不是针对Eventuate的。事件源解决方案很常见，他们需要开始考虑协调，这是他们通常的地方结束了。

由于您通常希望流程记住重启的位置，因此流程本身可能是事件源。乌龟一路下来。