postgresql – 使用事件源时存储事件

发布时间：2020-12-13 16:02:44 所属栏目：百科来源：网络整理

导读：我一直在阅读有关事件采购的内容,虽然我发现这是一个很自然的方法来解决几个问题,但我并不太了解如何将事件存储在实践中. 在互联网上搜索一下我发现this article由Vaughn Vernon谈论了一种简单的方法来存储DDD中的聚合.虽然它不是专门针对事件来源,但他提出

我一直在阅读有关事件采购的内容,虽然我发现这是一个很自然的方法来解决几个问题,但我并不太了解如何将事件存储在实践中.

在互联网上搜索一下我发现this article由Vaughn Vernon谈论了一种简单的方法来存储DDD中的聚合.虽然它不是专门针对事件来源,但他提出了一种使用PostgreSQL存储域事件的方法.

在他的方法中,我们有一个表具有一个id和一个JSON数据字段的事件.这给了很多自由,因为我们可以存储任何JSON数据,因此我们可以存储各种事件.

但是让所有事件都对应于单个表中的所有聚合,让我有点担心.

因此,当我们存储事件以使用事件采购时,我们应该如何进行？我可以看到三个选项：

>遵循文章中用于域事件的想法,并将所有内容存储在单个表中.
>每个事件创建一个表.这里的缺点是我们需要跟踪每个聚合的事件,并且对于每个聚合,可以有各种类型的事件.所以这很容易导致一个巨大的表号.
>为每个聚合创建一个表,并在那里存储该聚合的所有事件.虽然我们最终在同一个表中汇总了不同类型的事件,但它们都与相同的聚合相关.

这三个选项中哪一个更合理？如果没有,那么在使用事件采购时存储事件的正确方法是什么？

解决方法

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

听起来像FUD.

所有活动看起来都一样,对吗？一小段数据,以及一些元数据列,可用于将blob放在上下文中.你没有任何特别聪明的关系;在流中查找所有事件,查找由命令引起的所有事件(无论如何都将在同一个流中),这就是它.

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

在物理上,你可能想要四处走动,这样你就可以扩展.您可能想要查看Udi Dahan在CQRS but different slides中所说的内容.但这里的基本思想是分片/ partitioning是数据库供应商已经在解决的问题,所以让他们这样做.

Postgres活动商店的讨论：

> Konrad Garus
> Jeremy Miller

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!