Events 使用事件源时，数据是什么样子的？

我试图了解事件源是如何改变服务的数据体系结构的。我已经做了很多研究，但我似乎无法理解如何使用事件源正确存储数据

比如说，我有一项服务，可以跟踪运输包裹的车辆。数据模型的当前非关系结构是，每个文档表示一辆车辆，并且有许多字段表示起点位置、目的地位置、包裹类型、包裹数量、车辆状态等。通常会查询这些字段以获取要读取到前端的信息。当用户进行更改时，将对此文档进行适当的更改以更新此文档

通过事件源，似乎存储了每个事件的快照，但似乎有几种方法可以解释这一点：

首先，我描述的文档存在多个版本，每次更改时都会有一个新的快照。每个事件都将创建此文档的新版本并对其进行更改。这对我来说是最简单的方法，但我认为这是不正确的

我的另一种解释是，每个事件都存储有关文档中更改内容的特定信息。例如，当车辆状态从公路状态更改为可用状态时，会触发专门针对车辆状态更改的事件。假设它名为VehicleStatusUpdateEvent，包含车辆ID号、新状态和此事件的时间戳。因此，将存储此事件并将其发布到消息传递队列。从队列中提取时，将对文档的当前版本进行相应的更改。我可以理解这一点，但我认为我仍然有一些误解。我的理解是，事件源允许我们在每次更改时获得数据的快照，这样我们就可以知道它在任何时候的样子。我刚才描述的内容将保留更改日志，但仍然只有一个版本的文件，因为事件只包含整个文件的特定部分

有人能描述一下数据流和体系结构是如何与事件源一起工作的吗？使用我提供的车辆数据示例可能会帮助我更好地构建它。我觉得我已经接近了解这一点了，但我遗漏了一些我在网上搜索时似乎无法理解的基本内容

数据模型当前的非关系结构是每个文档代表一个载体

好的，让我们从这里开始

在您描述的数据模型中，文档的存储会破坏早期副本

现在想象一下，我们将文档存储在git存储库中。然后保存文档也将保存元数据，元数据将包含指向上一个文档的指针

当然，在这种情况下，我们可能有很多重复。因此，我们不再每次都存储完整的文档，而是存储一个补丁文档（想想），以及指向原始补丁的元数据

再次重申同样的想法，但我们不存储通用补丁文档，而是使用特定于域的消息来描述模型中正在发生的事情

这就是事件源实体的数据模型的样子：文档转换的特定于域的描述列表

当您需要重建当前状态时，您可以从您知道的状态开始（可能是文档发生任何事情之前的“null”状态），然后将此后发生的所有修补程序（事件）重播到该文档上

如果你想做一个临时查询，游戏是一样的，你重播事件直到你感兴趣的时间点

---

因此，在引用旧版本时，基本上是使用事件重建文档，对吗

是的，完全正确

那么，是否仍有“当前状态”文件，或者这被视为不良做法

“视情况而定”。在一般情况下，没有当前状态文档；只有按写顺序排列的事件列表是“真实的”，其他所有内容都是从中派生出来的

关于事件源的讨论通常会导致考虑使用专用的消息存储来管理这些有序列表的持久性，并且消息存储通常不支持文档存储。因此，尝试保持“当前版本”需要提交到两个不同的存储

此时，设计师通常会选择“最新版本”足够好了，在这种情况下，他们最终在事务边界之外构建文档的一致表示……或者他们认为当前版本很重要，并研究支持将当前版本存储在与事件相同的事务中的存储解决方案（例如：使用RDBMS）

使用事件生成所需快照的过程是什么

如果要生成快照，通常会使用一种称为“投影”的模式来迭代事件，然后将它们折叠或缩小以创建文档

大致上，你在某个地方有一个函数

document-with-meta-data = projection(event-history-with-metadata)

---

因此，在引用旧版本时，基本上是使用事件重建文档，对吗？那么是否仍然存在“当前状态”记录或者这被认为是不好的做法？从我一直在研究的内容来看，我一直从谁那里读到“是”和“否”，这让我相信这是主观的。不管怎样，使用事件生成快照的过程是什么？是程序中编写的方法，还是使用的工具？什么技术我会使用那个工具吗？