Myślę, że jest bardziej elastyczny, jeśli przechowujesz promotor jako część ładunku zdarzenia zamiast metadanych. Kwestie bezpieczeństwa powinny być rozwiązywane poza domeną. Nie każde zdarzenie jest zgłaszane przez użytkownika, chociaż możesz zrobić dla niego fałszywe (SysAdmin dla CronJob).
Na przykład:
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
}
Myślę, że wystarczą nazwy klas. Dodanie kolejnej tabeli komplikuje odczyt zdarzenia (przez łączenie tabel) i myślę, że dodaje wartość tylko wtedy, gdy nazwy klas są zmieniane (Aktualizuj jeden wiersz w tabeli typu zdarzenia). Ale myślę, że użycie
. nie sprawia większych problemówupdate domain_events set
aggregate_type = 'new class name'
where aggregate_type = 'origin class name'
Nie jestem pewien, czy rozumiem grupy wydarzeń, czy mógłbyś dodać więcej wyjaśnień?
Czasami zdarzenia są wykorzystywane do integracji wielu kontekstów. Ale każde wydarzenie jest poruszane tylko w jednym kontekście. Na przykład zdarzenie ManualPaymentMadeEvent jest wywoływane w kontekście zamawiania, a odbiornik zdarzeń w kontekście wysyłki również go wykorzystuje, uważając go za wyzwalacz rozpoczęcia wysyłki.
Wolę używać na użytkownika bazy danych (termin Oracle) na kontekst. shipping.domain_events dla kontekstu wysyłki i ordering.domain_events dla kontekstu zamówienia.
Oto schemat w axon-framework co może pomóc
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);