Jag tycker att det är mer flexibelt om du lagrar promotorn som en del av evenemangets nyttolast istället för metadata. Säkerhetsproblemen bör hanteras utanför domänen. Inte alla händelser tas upp av en användare, även om du kan göra en falsk för dem (en SysAdmin för CronJob).
Till exempel:
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
}
Jag tycker klassnamn räcker. Att lägga till ytterligare en tabell komplicerar läsning av händelser (genom att ansluta tabeller), och jag tror att det bara tillför ett värde när klassnamnen döps om (Uppdatera en rad i händelsetypstabellen). Men jag tror att det inte skapar mycket problem genom att använda
update domain_events set
aggregate_type = 'new class name'
where aggregate_type = 'origin class name'
Jag är inte säker på att jag förstår eventgrupper, kan du lägga till mer förklaring?
Ibland används händelserna för att integrera flera sammanhang. Men varje händelse tas bara upp i ett sammanhang. Till exempel, A ManualPaymentMadeEvent höjs i beställningssammanhang, och en händelselistare i fraktsammanhang konsumerar det också, betraktar det som triggern för start av leverans.
Jag föredrar att använda per databasanvändare (oracle term) per sammanhang. shipping.domain_events för fraktkontext och ordering.domain_events för beställningskontext.
Här är schemat i axon-framework vilket kan hjälpa
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);