cqrs - 使用 RDBMS 作为事件源存储

Question

如果我使用 RDBMS(例如 SQL Server)来存储事件源数据，架构会是什么样子？

我见过一些抽象意义上的变体，但没有具体的。

例如，假设有一个“产品”实体，对该产品的更改可能以以下形式出现:价格、成本和描述。我很困惑我是否会:

1. 有一个“ProductEvent”表，其中包含产品的所有字段，其中每次更改都意味着该表中的一条新记录，并酌情加上“谁、什么、哪里、为什么、何时和如何”(WWWWWH)。当成本、价格或描述发生变化时，会添加一个全新的行来代表产品。
2. 将产品成本、价格和说明存储在通过外键关系与产品表连接的单独表中。当这些属性发生更改时，请根据需要使用 WWWWWH 写入新行。
3. 将 WWWWWH 以及表示事件的序列化对象存储在“ProductEvent”表中，这意味着事件本身必须在我的应用程序代码中加载、反序列化和重播，以便重新构建应用程序状态给定的产品。

我特别担心上面的选项 2。极端情况下，产品表几乎是每个属性一个表，加载给定产品的应用程序状态将需要从每个产品事件表加载该产品的所有事件。我觉得这张 table 爆炸的味道不对。

我确信“这取决于”，虽然没有单一的“正确答案”，但我试图了解什么是可以接受的，什么是完全 Not Acceptable 。我还知道 NoSQL 可以在这里提供帮助，其中事件可以存储在聚合根中，这意味着只需向数据库发送一个请求即可获取事件以从中重建对象，但我们并没有使用 NoSQL 数据库这一刻我正在寻找替代方案。

Answer 1

事件存储不需要了解事件的特定字段或属性。否则，对模型的每次修改都将导致必须迁移数据库(就像老式的基于状态的持久性一样)。因此我根本不推荐选项 1 和 2。

下面是 Ncqrs 中使用的架构。如您所见，表“Events”将相关数据存储为 CLOB(即 JSON 或 XML)。这对应于您的选项 3(只是没有“ProductEvents”表，因为您只需要一个通用“Events”表。在 Ncqrs 中，到聚合根的映射是通过“EventSources”表进行的，其中每个 EventSource 对应于一个实际的聚合根。)

Table Events:
    Id [uniqueidentifier] NOT NULL,
    TimeStamp [datetime] NOT NULL,

    Name [varchar](max) NOT NULL,
    Version [varchar](max) NOT NULL,

    EventSourceId [uniqueidentifier] NOT NULL,
    Sequence [bigint], 

    Data [nvarchar](max) NOT NULL

Table EventSources:
    Id [uniqueidentifier] NOT NULL, 
    Type [nvarchar](255) NOT NULL, 
    Version [int] NOT NULL

Jonathan Oliver's Event Store implementation的SQL持久化机制基本上由一个名为“Commits”的表和一个 BLOB 字段“Payload”组成。这与 Ncqrs 中的几乎相同，只是它以二进制格式序列化事件的属性(例如，添加了加密支持)。

Greg Young 建议采用类似的方法，如 extensively documented on Greg's website .

他的原型(prototype)“事件”表的架构如下:

Table Events
    AggregateId [Guid],
    Data [Blob],
    SequenceNumber [Long],
    Version [Int]