使用事件溯源时存储事件

Question

我一直在阅读事件溯源的相关内容，虽然我认为这是解决几个问题的自然方法，但我并没有完全理解如何在实践中存储这些事件。

通过在互联网上搜索，我找到了 Vaughn Vernon 写的this article，讲述了在 DDD 中存储聚合的简单方法。虽然它并不特别关注事件溯源，但他提出了一种使用 PostgreSQL 存储领域事件的方式。

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

但是，将所有聚合对应的所有事件都存储在单个表中，让我有点担心。

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

1. 采用领域事件的思路，将所有内容存储在单个表中。

2. 为每个事件创建一个表。这里的缺点是我们需要跟踪每个聚合的事件，并且对于每个聚合可能会有各种各样的事件。因此，这很容易导致表数量庞大。

3. 为每个聚合创建一个表，并将该聚合的所有事件存储在其中。虽然我们最终会得到不同类型的事件汇集在同一张表中，但它们都与同一聚合相关。

这三个选项中哪一个更合理？如果都不行，使用事件溯源时应该如何存储事件？

- user1620696

Answer 1

但是，将所有聚合的事件对应到单个表中，让我有些担心。

听起来像是恐慌宣传。

所有事件看起来都是一样的，对吧？一堆数据和一些元数据列，这些元数据对于将数据放入上下文非常有用。您没有特别聪明的关系需要运行；查找流中的所有事件，查找由命令引起的所有事件（这些事件无论如何都会在同一个流中），就是这样。

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

从物理上讲，您可能希望开玩笑以便进行扩展。您可能需要查看Udi Dahan在CQRS but different 幻灯片中提到的内容。但基本思想在于，分片/分区是数据库供应商已经在解决的问题，所以让他们去解决吧。

Postgres事件存储的讨论：

• Konrad Garus
• Jeremy Miller

（原文已经是英文了，这里直接返回原文）

- VoiceOfUnreason