用于事件源的关系数据库架构 [英] Relational database schema for event sourcing

问题描述

我正在尝试将域事件存储在postgres数据库中。我不确定很多事情，以后也不想重新设计这种结构，因此我正在寻求具有活动外包经验的人员的指导。我目前有下表：

I am trying to store domain events in a postgres database. I am not sure in many things, and I don't want to redesign this structure later, so I am seeking for guidance from people who have experience with event sourcing. I have currently the following table:

domain events
    version - or event id, integer sequence, helps to maintain order by replays
    type - event type, probably classname with namespace
    aggregate - aggregate id, probably random string for each aggregate
    timestamp - when the event occured
    promoter - the promoter of the event, probably user id
    details - json encoded data about the properties

我不是的json编码数据确定：

What I am not sure:

1. 我应该存储域事件的发起人吗？
   
   可以帮助您通过以下方式找到受感染的帐户安全性受到破坏，但是
   我不知道例如通过CRONjob存储什么。


2. 我应以哪种格式存储事件类型？
   
   我应该添加具有事件类型的表，还是类名足够？
   
   我应该添加事件组吗？


3. 我对受限上下文的定义感到困惑。据我所知，每个聚合都可以有多个有界上下文，因此我可以在多个模块中使用单个聚合的不同方面。这听起来不错，因为例如帐户可以与许多事物相关，包括身份验证，授权，用户个人资料，用户帖子，用户合同等...
   
   我不确定，该域事件可以具有多个有界上下文，也可以只有一个，因此我也应该存储事件上下文吗？ （对于某些情况，我想重播与单个上下文相关的事件）
   
   如何在单个聚合类中实现这么多属性，我应该使用某种组合吗？

推荐答案

1。我应该存储域事件的启动子吗？

1.Should I store the promoter of the domain event?

我认为，如果将启动程序存储为事件有效负载的一部分而不是元数据，它会更加灵活。安全问题应在域外处理。尽管您可以为用户创建一个假事件（CronJob的SysAdmin），但并不是每个用户都会引发该事件。

I think it's more flex if you store the promoter as part of the event payload instead of meta data. The security concerns should be handled outside the domain. Not every event is raised by a user, although you could make a fake one for them(a SysAdmin for CronJob).

例如：

ManualPaymentMadeEvent { //store this object as details in your schema
    amount,
    by_user//In this case, developers can determine whether store the promoter case by case
}

2。我应该以哪种格式存储事件类型？

是否应该添加带有事件类型的表，或者类名够吗？
我应该添加事件组吗？

2.what format should I store the event type?
Should I add a table with event types, or are the class names enough? Should I add event groups?

我认为类名就足够了。添加另一个表会使事件读取（通过连接表）复杂化，并且我认为它仅在重命名类名时才增加值（更新事件类型表中的一行）。但是我认为使用

I think class names is enough. Adding another table complicates event read(by join tables), and I think it only adds value when the class names is renamed(Update one row in event type table). But I think it does not add much trouble by using

update domain_events set 
    aggregate_type = 'new class name'
where aggregate_type = 'origin class name'

我不确定我是否了解事件组，您能添加更多的解释吗？

I'm not sure that I understand event groups, could you add more explanation?

3。我不确定域事件可以有多个有限上下文，也可以只有一个第一，所以我应该将事件上下文存储为
吗？

3.What I am unsure, that a domain event can have multiple bounded contexts, or just a single one, so should I store event contexts as well?

有时，事件用于集成多个上下文。但是每个事件仅在一个上下文中引发。例如，在订购上下文中引发了ManualPaymentMadeEvent，并且装运上下文中的事件列表器也将其消耗掉，将其视为开始装运的触发器。

Sometimes the events are used to integrate multiple contexts. But each event is raised only in one context. For example, A ManualPaymentMadeEvent is raised in ordering context, and an event listner in shipping context also consumes it, regards it as the trigger of start shipping.

我更喜欢按上下文使用每个数据库用户（oracle术语）。

I prefer to use per database user(oracle term) per context. shipping.domain_events for shipping context and ordering.domain_events for ordering context.

这是轴心框架可能会帮助

create table DomainEventEntry (
    aggregateIdentifier varchar2(255) not null,
    sequenceNumber number(19,0) not null,
    type varchar2(255) not null,  --aggregate class name
    eventIdentifier varchar2(255) not null,
    metaData blob,   
    payload blob not null, -- details
    payloadRevision varchar2(255),
    payloadType varchar2(255) not null, --event class name
    timeStamp varchar2(255) not null
);

alter table DomainEventEntry
    add constraint PK_DomainEventEntry primary key (aggregateIdentifier, sequenceNumber, type);

这篇关于用于事件源的关系数据库架构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！