AKKA持久性演员

Question

1 - 有人可以解释为什么在AKKA持久性演员中，更新 状态是在其事件被记录后完成的？

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

（我觉得我挺懂事，但我的困惑来自于如何，我无法理解一个命令的处理。我不认为这是什么，从处理的事件不同见下文）

2 - 是否有执行/处理命令 的和之间的差的“更新状态回调”，这是可能与事件的处理 。

2.1 - 换句话说，应该去哪里处理命令，以及应该在哪里处理事件。这两个“处理” 必然不同。

我所看到的大多是所有的例子表明，没有什么具体的有关处理除了验证，然后坚持它的相关事件，并相应地更新状态的演员以外的命令。

这意味着处理命令在某种程度上处理事件。这意味着通风口不能被记录下来

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

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

这只是感觉很奇怪。因此，从某种意义上说，除了被验证之外，命令从不触发任何东西，特别是如果它与更新某件事有关，而是放置一个事件，然后触发真正的工作。

于是命令在这里简单地说，如果一个事件就发生过这种地方活动 居然会后成为现实。也就是说，它是为了恢复目的而完成的。

它是混乱

Answer 1

的命令是改变数据的请求。一个事件是一个应用的变化，并在事实之后。在记录事件之前对数据的更改进行验证。日志记录事件被认为是保证成功的更新，因为它在应用验证之后持续存在。当执行者重新补水时，它会重放所有更改，并相应地更新状态，并保证可以应用所有更新。这是之后国家采用这个国家的基本原因。你看到的模式被称为事件采购。我认为这presentation解释得很好。

Answer 2

最近（Dec.2016）的文章“Akka event sourcing done right”由Filippo De Luca提出的通常的工作流程，其中（通常的工作流程）是一种替代：

持久演员流动看起来像这样通常：

• A命令是由接收演员
• 命令在基于Actor状态的事件中被转换。
• 事件被持久
• 的演员状态响应被修改为事件

该流具有在第二步骤的主要缺点。如果翻译此命令（或刺激）的逻辑被窃听，则原意将失去。

但菲利波提供了另一个视角：

在我目前使用的应用程序，一个持久的演员是在响应一堆卡夫卡的主题得到了一些外部事件。在坚持这些事件之前，这些事件会转化为本地事件。这种转换取决于当前的Actor状态，其中包含许多未来可能会改变的业务规则。
这个逻辑中的错误使得整个事件源代码体系结构变得毫无意义。

我认为，一个更好的模式是遵循这种逻辑在事件发生后一直坚持：

• 的命令由演员
• 的命令是坚持
• 的命令是施加的接收到已修改的Actor状态。

我的建议是完全放弃第二步，将外部命令作为事件处理，并将其存储在日志中。在这种情况下，即使我们在代码适用命令状态的错误，我们可以修复它，并会追溯适用

然而，雷纳托Cavlacanti评论

在CQRS的背景下，域名事件不是一种刺激。它只是表示发生了一些对您的域有商业价值的事情。
一个事件可以被解释并触发一些其他动作。在这种情况下，它可以被看作是一种刺激，但这不是它的第一意图。

关于命令采购的想法，它可以完成，但它的适用性是有限的。 主要原因是命令处理程序必须是纯的。必须没有副作用，没有远程调用，没有IO，没有任何东西。只是纯粹的函数调用您的聚合数据。这是因为你想重新播放它们并获得相同的结果。

菲利普承认：

你得到了一点：在我们的场景中大多数命令实际上是被其他服务发送的事件。我们存储它们，然后我们对模型应用更改。我们应用更改的方式可能因业务要求而异。但他们当然不能被拒绝，无论如何都需要坚持。

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

我也会说我们可能想要拒绝一个命令而不是坚持任何东西（而且我们）。