我可以为其他角色持久化事件吗？

Question

使用akka-typed，我试图创建一个事件源应用程序，在这个应用程序中，一个actor上的命令可以对另一个actor造成影响。具体来说，我有以下情况。

• RootActor
• BranchActor (它是根的子代的表示)

当RootActor被发出一个 CreateBranch 命令，进行验证，如果一切正常，结果一定是这样。

1. RootActor将更新该演员的子代列表。
2. BranchActor将用一些内容（之前在命令中给出的）进行初始化。
3. RootActor对命令的发布者的回复为 OperationDone

现在我唯一能想到的是。RootActor处理这个事件，然后作为一个副作用 向BranchActor发出一个命令，BranchActor保存一个初始化的eventt，然后回复给RootActor，最后回复给原来的发布者。

不过这看起来太复杂了，因为。

1. 我需要使用一个管道到自己的机制，这意味着：
   • 我也需要管理内部命令，让我可以回复原发件人
   • 我需要管理该操作可能失败的情况，如果失败了，就意味着分支的创建被 非原子而保存两个事件是原子性的，即要么两个都保存，要么都不保存。
2. 我需要向另一个角色发出另一条命令，但我不应该这样做，因为主命令应该处理好所有的事情。
3. 新的命令应该是有效的，尽管这不是必要的，因为在这种情况下，它来自系统而不是 "外部 "用户。

那么我的问题是：我不能直接从系统中保存。RootActor 两个事件，一个是自己的，一个是目标的。BranchActor另外，作为一个额外的问题：这对事件源来说是一个好的做法吗？

Answer 1

那么我的问题是：我不能从RootActor中保存两个事件，一个是自己的，一个是目标BranchActor的吗？

不，听起来很老套，但你能对一个actor做的唯一事情就是向它发送消息。如果你一定要做你正在做的事情，你的道路是正确的。如管到等。

这就算是事件源的好做法吗？

这不是一个好的做法。到底是次优还是平反模式，还是值得商榷的。(我觉得我之所以自信地说这句话，是因为这一点 Lightbend讨论线 在那里辩论，一方认为 "棘手，但我不后悔"，另一方认为 "明确的反模式"）。)

引用某人在内部Slack中的一段话(未经他的允许，我不想将其归于他，但我把它保存下来，因为它似乎很优雅地概括了这种情况)。

如果一个事件来源的actor需要联系另一个actor来决定是否可以持久化一个事件，那么我们就不是在建模一个一致性边界了。它应该只依赖于[它所拥有的]范围内的状态（自己的状态和传入的命令）。......所有的体操（坚持其等待确认的事实，储藏，管道到自己）来使它正常工作，这表明我们没有尊重一致性边界。

如果你不能修复你的聚合，使一个行为者负责整个一致性边界，更好的做法是事先丰富命令：本质上建立一个Saga模式。