事件源中“当前状态”存储在哪里？

Question

我了解 cqrs，但我在事件源的一部分方面遇到问题。每个人都说“您不存储聚合的当前状态，您存储应用于该聚合的事件序列”。我没意见。但为了应用命令并产生事件，您需要当前的聚合状态。以此表为例（它是 API 调用的序列）。假设我有这样的业务规则：“一个帖子最多可以更新两次”。

在此示例中，第三次编辑帖子的尝试应该会失败，并且不应生成和存储任何事件。假设我们没有使用“从事件存储中获取所有事件、构建聚合、应用命令、生成事件、存储事件”的方法。在这种情况下，当前聚合的状态存储在哪里？ 如果它存储在某个地方，这不是违背了“你不存储聚合..”吗？

我在互联网上阅读了几篇文章、演讲和示例。但我总是得出相同的结论/答案。我见过人们利用投影来检查域不变量/业务规则，但投影最终是一致的，并可能导致竞争条件。

Answer 1

我了解 cqrs，但我在事件源的一部分方面遇到问题。

不是你的错；文学很糟糕。

---

我见过人们利用投影来检查域不变量/业务规则，但投影最终是一致的，并可能导致竞争条件。

您不会遇到竞争条件，因为人们正在使用（逻辑）锁来防止历史记录上的写入冲突。去掉分散注意力的细节，幸福的道路看起来像这样：

acquire lock
read previous events
compute new events
write new events
release lock

在实践中，通常改用条件写入，使用流元数据来确保域逻辑运行时没有任何更改

read previous events
compute new events
acquire lock
write-if new events
release lock

思考“比较和交换”。

通常这是通过通用元数据完成的；仅当历史记录的当前版本与历史记录的“预期版本”匹配时，我们才执行写入（例如，历史记录中仍然具有与我们开始时相同数量的事件）。

Answer 2

假设我们没有使用“从事件存储中获取所有事件、构建聚合、应用命令、生成事件、存储事件”的方法。在这种情况下，当前聚合的状态存储在哪里？如果它存储在某个地方，这不是违背了“你不存储聚合..”吗？

好吧，如果您不打算使用获取事件的方法来重建聚合，并且您也不想维护和存储当前状态..您只是将自己限制在几乎不可能的情况下。

您为什么不想根据事件重建聚合？这是事件溯源的一个非常基本的部分。 存储当前状态虽然不是严格必要的，但对于事件溯源来说也是非常重要的。但正如您所说，在将命令应用于聚合时，您要小心使用投影（存储的当前状态），因为它们通常“仅”最终一致，因此在某些业务规则/不变量需要时可能不适合使用以确保。