postgresql - 使用事件溯源时存储事件

Question

我一直在阅读有关事件溯源的文章，虽然我发现它是解决几个问题的一种非常自然的方法，但我不太了解如何在实践中存储事件。

在互联网上稍微搜索了一下，我找到了 this article Vaughn Vernon 讲述了一种在 DDD 中存储聚合的简单方法。虽然它不是专门针对事件溯源的，但他提出了一种使用 PostgreSQL 存储域事件的方法。

在他的方法中，我们有一张表 Events，其中包含一个 id 和一个 JSON data 字段。这提供了很大的自由度，因为我们可以存储任何 JSON 数据，因此我们可以存储各种事件。

但是让所有事件对应于一个表中的所有聚合，让我有点担心。

那么，当我们存储事件以使用事件溯源时，我们应该如何进行呢？我可以看到三个选项:

1. 遵循文章中用于域事件的想法，将所有内容存储在一个表中。

2. 为每个事件创建一个表。这里的缺点是我们需要跟踪每个聚合的事件，并且每个聚合都可以有各种事件。所以这很容易导致表数很大。

3. 为每个聚合创建一个表，并在其中存储该聚合的所有事件。尽管我们最终将不同类型的事件放在同一个表中，但它们都与同一个聚合相关。

这三个选项中哪个更合理？如果没有，使用事件溯源时存储事件的正确方法是什么？

Answer 1

But having all the events corresponding to all the aggregates in a single table, makes me a little worried.

听起来像 FUD。

所有事件看起来都一样，对吧？数据 blob，以及一些有助于将 blob 置于上下文中的元数据列。你没有什么特别聪明的关系可以经营；在流中查找所有事件，查找由命令引起的所有事件(无论如何都将在同一个流中)，仅此而已。

事件可能都属于同一个逻辑 View 。

从 body 上来说，您可能想四处游荡以便扩大规模。您可能想回顾一下 Udi Dahan 在 CQRS but different 中所说的话slides .但这里的基本思想是分片/partitioning数据库供应商已经在着手解决这个问题，所以让他们来解决吧。

Postgres 事件存储的讨论:

• Konrad Garus
• Jeremy Miller