Schéma relační databáze pro získávání událostí

Myslím, že je flexibilnější, pokud místo metadat uložíte promotéra jako součást užitečného zatížení události. Bezpečnostní problémy by měly být řešeny mimo doménu. Ne každá událost je vyvolána uživatelem, i když pro ně můžete vytvořit falešnou (SysAdmin pro CronJob).

Například:

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
}

Myslím, že názvy tříd stačí. Přidání další tabulky komplikuje čtení událostí (pomocí sloučení tabulek) a myslím, že přidává hodnotu pouze tehdy, když jsou názvy tříd přejmenovány (aktualizace jednoho řádku v tabulce typů událostí). Ale myslím si, že použití

nepřinese mnoho problémů

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

Nejsem si jistý, zda rozumím skupinám událostí, můžete přidat další vysvětlení?

Někdy se události používají k integraci více kontextů. Ale každá událost je nastolena pouze v jednom kontextu. Například událost ManualPaymentMadeEvent je vyvolána v kontextu objednávky a seznam událostí v kontextu přepravy ji také spotřebuje a považuje ji za spouštěč zahájení přepravy.

Dávám přednost použití na uživatele databáze (výraz Oracle) na kontext. shipping.domain_events pro kontext dopravy a ordering.domain_events pro kontext objednávky.

Zde je schéma v axon-framework což by mohlo pomoci

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