Relational database schema for event source

Question

I am trying to save domain events in a postgres database. I’m not sure about many things, and I don’t want to redo this structure later, so I am looking for guidance from people who have experience working with the source of events. I currently have 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 

What I'm not sure:

• Should I keep a domain event promoter?
  This may help to find a compromised account as a result of security breaches, but I do not know what to store, for example, CRONjob.
• In what format should I store the type of event?
  Should I add a table with event types or are class names enough?
  Should I add event groups?
• I was confused by the definition of a limited context. As far as I know, each aggregate can have several limited contexts, so I can use different aspects of the same aggregate in several modules. This sounds good, because, for example, accounts can be associated with many things, including authentication, authorization, user profile, user messages, user contracts, etc. ... that I'm not sure that a domain event can have some limited contexts or only one, so should I also store event contexts? (for cases I want to reproduce events related to one context)
  How to implement so many properties in one class of aggregates, should any composition be used?

Answer 1

1. Do I have to store a domain event promoter?

I think it will be more flexible if you save the promoter as part of the event payload instead of metadata. Security issues should be addressed outside the domain. Not every event occurs by the user, although you can make a fake one for them (SysAdmin for CronJob).

For instance:

 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. What format should I store the type of event?
Should I add a table with event types or are class names enough? Should I add event groups?

I think class names are enough. Adding another table complicates the reading of events (according to connection tables), and I think that it only adds value when class names are renamed (update one row in the event type table). But I think that it does not cause much problems when using

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

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

3. What I'm not sure that a domain event can have several restricted contexts or only one, so I have to store event contexts as well?

Events are sometimes used to integrate multiple contexts. But each event occurs in only one context. For example, in the context of ordering, the ManualPaymentMadeEvent function is created and also uses the list of events in the delivery context, considering it as a trigger to start sending.

I prefer to use a database (oracle term) for each user for each context. shipping.domain_events for the delivery context and order.domain_events for the order context.

Here is a diagram in the axon framework that might help

 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);