我已经在 Scala 中涉足了一段时间，并且从远处研究了 Akka，并且终于投入其中。FSM 特性为我敲定了交易。让我担心的是，我可能已经设想过如何不恰当地共享数据，并且我可能已经错误地设想了事件处理循环以匹配 Akka 最佳实践。
在我的问题中，我有一个中央协调器，他会将传入的任务请求匹配到也是有限状态机的适当参与者。我最初假设 onTransition 不仅会给出状态名称，还会给出状态数据。
我想传统的数据封装将是不将该数据暴露给听众的原因。但对我来说，我有两个用途让其他人看到这些数据。
状态数据包含一个基础域对象，其属性用于根据其要求确定哪些参与者是处理工作的最佳人选。由于工作要求是动态的，我对单独收集工人演员犹豫不决（尽管我不确定为什么这会让我停下来）。
查询所有满足其他先决条件的单独参与者并加入所有回复的想法对 Akka 来说效率低下或至少不习惯。我还需要在 UI 中显示当前状态，并且没有理由使用相同的事件队列来查看状态。
无论如何，我正在考虑让 FSM 更新一个代理，但由于那是一个演员本身，我不确定那层间接会给我带来什么，而且它可能会使对事件顺序的推理变得更加困难。
Fowler 的 Event Collaboration 指出我要明确发送状态数据，但我希望有一种更简单的方法来为所有自动更新状态数据的转换执行此操作。
我也很难理解事件级联的顺序，以及我是否需要控制它。即使我所有传入的外部事件都来自单个参与者，我仍希望在处理下一个外部事件之前将所有内部生成的事件处理给所有其他参与者。我正在考虑让中央协调员使用！等待回复，但我担心如果不小心删除了事件链中某处的一个感叹号，我将失去该保证。
我正在考虑解决此问题的解决方案包括使用优先级事件，以便为内部事件赋予更高的优先级，对所有共享的“内部”参与者使用单线程调度程序（可能是工作窃取？）。
我正在尝试做的事情是否涉及最佳实践，或者我是否尝试做错误的事情:)？