AKKA演员

Question

1-有人可以解释一下，为什么在AKKA永久演员中，记录了事件后才进行状态更新？

1.1-如果在更新状态“回调”发生之前系统崩溃，将会发生什么？

（我想我有点理解，但是我的困惑来自我无法理解命令的处理。我认为它与处理事件没有什么不同。请参阅下文）

2-命令的执行/处理与与事件的处理有关的“更新状态回调”之间是否存在差异。

2.1-换句话说，命令应该放在哪里，事件应该放在哪里。 这两个“处理方式”必然不同吗？

我所看到的所有示例大部分都表明，除了验证命令然后保留其关联事件并相应地更新actor状态外，处理命令没有什么特别的。

这意味着处理命令毕竟在某种程度上处理了一个事件。 这意味着排气孔无法记录

我感到困惑的是，一个事件只能记录发生的事情。 但是在我所看到的所有示例中，在接收到命令后，没有什么特别的事情发生，如果只是实际上，则设置执行动作的事件（哪一个？）然后更新状态。 这在某种程度上颠倒了事物的逻辑。

如果命令是创建订单，那么我们可能会在验证后自动创建一个order_was_created，然后在更新状态函数之后根据事件接收来更新actor的状态。

感觉很奇怪。 因此，从某种意义上讲，一个Command除了经过验证之外，永远不会触发任何事情，尤其是在它与更新某些东西有关的情况下，而是放置一个事件，然后它将触发实际的工作。

因此，这里的司令部只是在说一个事件是否发生了，该事件之后将在哪里真正实现。 也就是说，此操作是出于恢复目的而进行的。

令人困惑

Answer 1

命令是更改数据的请求。 事件是事实之后的已应用更改。 在记录事件之前，先验证数据更改。 日记事件被视为保证成功更新，因为在应用验证后该事件将保留下来。 当持久性参与者补水时，它将重放所有更改，并相应地更新状态，并保证可以应用所有更新。 这是随后应用状态的基本原因。 您看到的模式称为事件源。 我认为此演示文稿可以很好地解释它。

Answer 2

Filippo De Luca最近（2016年12月）的文章“ Akka事件采购正确完成 ”提出了一种替代常规工作流程的方法，该常规工作流程为：

持续的actor流通常如下所示：

• 演员收到命令
• 命令会根据参与者的状态在事件中进行翻译。
• 该事件持续存在
• Actor状态会根据事件进行修改

在第二步骤中，该流程具有主要缺点。 如果翻译此命令（或刺激）的逻辑遭到错误干扰，那么最初的意图就会丢失。

但是Filippo提供了另一种观点：

在我目前正在使用的应用程序中，一个持久的Actor响应从一系列Kafka主题收到的一些外部事件。 这些事件在持久化之前会转换为本地事件。 这种转换取决于当前Actor的状态，其中包含许多将来可能会更改的业务规则。
这种逻辑中的错误使整个事件源架构毫无意义。

我认为一个更好的模型是在事件持续后应用此逻辑：

• 演员收到命令
• 命令被保留
• 命令将应用于已修改的Actor状态。

我建议的是完全放弃第二步，并将外部命令视为事件，并将其存储在日志中。 在这种情况下，即使我们在将命令应用于状态的代码中存在错误，我们也可以对其进行修复，并将其追溯应用

但是，Renato Cavlacanti评论

在CQRS的上下文中，域事件不是刺激。 它仅表示已发生的事情对您的网域具有一定的商业价值。
事件可以被解释并触发其他动作。 在那种情况下，它可以被视为一种刺激，但这并不是它的初衷。

关于命令源的想法，虽然可以做到，但适用性有限。 主要原因是命令处理程序必须是纯净的。 一定没有副作用 ，没有远程调用，没有IO，什么也没有。 仅对您的汇总数据进行纯函数调用。 这是因为您想重播它们并获得相同的结果。

菲利波认识到：

您明白了：在我们的场景中，大多数命令实际上是另一个服务发送的事件。 我们存储它们，然后将更改应用于模型。 我们应用更改的方式可能会因业务需求而异。 但是，它们当然不能被拒绝，无论如何都必须坚持下去。

我同意它们不是命令，它们是外部事件。

我还要说的是，我们可能想拒绝一个Command（并且我们这样做）而不保留任何内容。