design-patterns - 事件源模式 : why mustn't I store current state?

Question

我正在学习事件采购模式我无法理解一件事。

有说明到不是 在许多教程中将实体的当前状态存储在 DB 中。开发人员应该构建一个基础结构，用于从 DB 中提取与所需实体相关的所有事件(“事件流”)，然后将它们应用于新的所需类型对象，因此最终是当前状态。

让它成为一个银行账户。要返回给我的客户她当前的帐户状态，我必须:

提取所有相关事件(数据库中可能有数千个事件)

计算当时的免费货币数量。

但是性能呢？我认为最好只存储每个帐户的当前状态，新事件会立即对其产生副作用。我不对吗？

Answer 1

事件溯源的全部意义在于将状态保持为一系列变化，因此拥有当前状态与 ES 是相反的。

话虽如此，由于性能要求有时 snapshot创建这样的更新不是从一开始就应用，而是从快照向前应用。事件存储是专门针对使用事件源的应用程序的数据库，它们可以提供快照功能 out of the box .

等式的另一部分是 ES 与 CQRS - Command Query Responsibility Segregation 互补分离读写模型的模式(上一个链接不太正确，IMO，您可能想查看 this one )。然后使用正在执行的命令或域事件来不断更新读取模型，该模型实际上是当前状态的非规范化表示。因此，对于命令，您将从事件 (ES) 构建域对象并对其进行操作，而对于查询，您将绕过事件存储并直接从读取模型中检索数据，读取模型可以是关系数据库、文档数据库或其他优化的东西适合您的阅读场景。

如果您有主要阅读应用程序，那么使用 ES 实现的命令端的性能可能不是那么重要。

ES 的好处超出了这个问题的范围，您可以在互联网上找到很多信息(尤其是 Greg Young 和 Udi Dahan)。我个人对此持怀疑态度，并且发现如果处理长期运行的业务场景是有意义的。