Eu acho que é mais flexível se você armazenar o promotor como parte da carga útil do evento em vez de metadados. As preocupações de segurança devem ser tratadas fora do domínio. Nem todo evento é gerado por um usuário, embora você possa criar um falso para eles (um SysAdmin para CronJob).
Por exemplo:
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
}
Acho que nomes de classe são suficientes. Adicionar outra tabela complica a leitura do evento (por tabelas de junção), e acho que só agrega valor quando os nomes das classes são renomeados (atualizar uma linha na tabela de tipos de eventos). Mas acho que não adiciona muitos problemas usando
update domain_events set
aggregate_type = 'new class name'
where aggregate_type = 'origin class name'
Não tenho certeza se entendi os grupos de eventos. Você poderia adicionar mais explicações?
Às vezes, os eventos são usados para integrar vários contextos. Mas cada evento é gerado apenas em um contexto. Por exemplo, um ManualPaymentMadeEvent é gerado no contexto de pedido e um ouvinte de eventos no contexto de envio também o consome, considerando-o como o gatilho do início do envio.
Eu prefiro usar por usuário de banco de dados (termo oracle) por contexto. shipping.domain_events para contexto de envio e ordering.domain_events para contexto de pedido.
Aqui está o esquema em axon-framework o que pode ajudar
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);
