我尝试使用akka类型来创建一个事件源应用程序，其中一个参与者的命令可以对另一个参与者产生影响。
- 根执行元
- BranchActor（它是根目录的子目录的表示形式）
当向RootActor发出CreateBranch命令时，将进行验证，如果一切正常，则结果必须为：
- RootActor将更新该执行元的子级列表
- BranchActor将使用一些内容（之前在命令中给出的）进行初始化
- RootActor使用
OperationDone回复命令的发布者
现在我唯一能想到的就是：RootActor处理事件，并作为副作用向BranchActor发出命令，BranchActor进而保存初始化事件，并回复RootActor，RootActor最终回复原始发布者。
不过，这看起来太复杂了，因为：
- 我需要使用管道来自我机制，这意味着
- 我还需要管理允许我回复原始发布者的内部命令
- 我需要管理该操作可能失败的情况，如果失败，则意味着创建分支 * 不是原子的 *，而保存两个事件是原子的，即要么两个都保存，要么两个都不保存。
- 我需要向另一个参与者发出另一个命令，但我不需要这样做，因为主命令应该处理所有事情
- 应验证新命令，但这不是必需的，因为在本例中，它来自系统而不是“外部”用户。
我的问题是：我能不能从RootActor中保存两个事件，一个用于自己，另一个用于目标BranchActor？另外，作为附加问题：对于事件外包来说，这是一个好做法吗？
1条答案
按热度按时间zfycwa2u1#
不。不是听起来陈腐，但你唯一能对演员做的就是向它发送一个信息。如果你必须做你正在做的事情，你就在正确的道路上。（例如，pipeTo等）
这不是一个好的实践。它是次优的还是完全的反模式仍然是有争议的。（我觉得我这么说很有信心，因为在这个Lightbend Discussion thread中，一方争论说“棘手，但我没有遗憾”，另一方争论说“显式的反模式”。）
引用一个内部Slack中的某个人的话（我不想在没有他的允许的情况下给他打分，但我保存了它，因为它似乎很优雅地总结了这种情况。）
如果一个事件源参与者需要联系另一个参与者来决定它是否可以持久化一个事件，那么我们就不再对一致性边界进行建模了。（自身状态和传入命令）...所有体操动作（坚持其等待确认、隐藏、管道到自己的事实）使其正常工作是一个迹象，表明我们没有尊重一致性边界。
如果您无法修复聚合，使一个参与者负责整个一致性边界，则更好的做法是事先丰富命令：本质上是建立一个 Saga 模式。