1 - 有人可以解释，为什么在AKKA Persistent Actors中更新 状态在记录事件后完成？
1.1 - 如果在更新状态＆＃34;回调＆＃34;之前会发生什么？发生了，系统崩溃了？
（我想我有点理解但是我的困惑来自于我无法理解命令的处理方式。我不认为它是不同的东西处理事件。见下文）
2 - 命令的执行/处理之间是否存在差异 和＃34;更新状态callBack＆＃34;这与处理有关 一个事件。
2.1 - 换句话说，应该去哪里处理Command，以及应该在哪里处理事件。那两个＆＃34;处理＆＃34; 必然不同。
我所看到的所有示例主要表明除了验证命令之外没有具体的处理命令，然后持久保存其相关事件并相应地更新actor状态。
这意味着处理命令毕竟有点处理事件。这意味着通风口无法记录
我的困惑在于，事件只能记录已发生的事情。但是在我看到的所有示例中，一旦收到命令，就没有特别的事情发生，如果它只是实际的，设置动作执行的事件（哪一个？）然后更新状态。这有点扭转了事物的逻辑。
如果命令是创建订单，那么我们可能会在验证后自动生成order_was_created，然后在更新的状态函数之后，根据事件接收更新actor的状态。
这感觉很奇怪。从某种意义上说，除了被验证之外，命令从不触发任何东西，特别是如果它与更新某些东西有关，但是放置一个事件然后将触发真正的工作。
所以一个命令在这里简单地说一个事件是否发生了，在哪里 事件真的会在之后成为现实。也就是说，它是为了恢复目的而完成的。
令人困惑
答案 0 :(得分：1)
命令是更改数据的请求。事件是应用的变更，事后是。在记录事件之前验证对数据的更改。记录的事件被视为保证成功更新，因为它在应用验证后保持不变。当持久性actor重新水合时，它会重放所有更改，并相应地更新状态，并保证可以应用所有更新。这是之后应用国家的基本原因。您看到的模式称为事件采购。我认为presentation解释得很好。
答案 1 :(得分：0)
最近（2016年12月）的文章＆＃34; Akka event sourcing done right ＆＃34; Filippo De Luca提出了通常的工作流程的替代方案，其中（通常的工作流程）是：
持久化演员流通常如下所示：
- 演员收到命令
- 命令根据Actor状态转换为事件。
- 事件持续存在
- 修改了Actor状态以响应事件
该流程在第二步中具有主要缺点。如果翻译此命令（或刺激）的逻辑被窃听，则原始意图将丢失。
但菲利波提供了另一个观点：
在我正在工作的应用程序中，持久的Actor正在响应从一堆Kafka主题收到的一些外部事件。在持久化之前，这些事件将转换为本地事件。这种转换取决于当前的Actor状态，包含许多将来可能发生变化的业务规则 这种逻辑中的一个错误使得整个事件采购架构毫无意义。
我认为更好的模型是在事件持续后应用此逻辑：
- 演员收到命令
- 命令已持久
- 该命令应用于已修改的Actor状态。
我建议完全放弃第二步并将外部命令视为事件，将其存储在日记中。在这种情况下，即使我们在将代码应用于状态的代码中存在错误，我们也可以修复它，并且它将被追溯应用
然而，Renato Cavlacanti评论
在CQRS的背景下，域事件不是刺激因素。它只表示发生了一些对您的域有一定商业价值的事情 可以解释事件并触发其他一些操作。在这种情况下，它可以被视为一种刺激，但它并不是它的第一个意图。
关于命令采购的想法，它可以完成，但它的适用性是有限的。 主要原因是命令处理程序必须是纯粹的。必须没有副作用，没有远程调用，没有IO，没有任何东西。只是纯函数调用您的聚合数据。这是因为你想重新播放它们并获得相同的结果。
Filippo承认：
您明白了一点：在我们的场景中，大多数命令实际上是由另一个服务发送的事件。我们存储它们然后我们将更改应用于我们的模型。我们应用更改的方式可能因业务需求而异。但当然，他们不能被拒绝，无论如何都需要坚持下去。
我同意他们不是命令，他们是外部事件。
我也会说我们可能想要拒绝一个命令（我们这样做），而不是坚持任何东西。