イベントソーシング用のリレーショナルデータベーススキーマ

メタデータではなくイベントペイロードの一部としてプロモーターを保存すると、より柔軟になると思います。セキュリティ上の懸念は、ドメイン外で処理する必要があります。すべてのイベントがユーザーによって発生するわけではありませんが、ユーザーのために偽のイベント（CronJobのSysAdmin）を作成することはできます。

例：

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
}

クラス名で十分だと思います。別のテーブルを追加すると、イベントの読み取りが複雑になり（テーブルの結合による）、クラス名の名前が変更された場合にのみ値が追加されると思います（イベントタイプテーブルの1行を更新します）。でも

を使ってもそれほど問題ないと思います

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

イベントグループを理解しているかどうかわかりませんが、さらに説明を追加していただけますか？

イベントは、複数のコンテキストを統合するために使用される場合があります。ただし、各イベントは1つのコンテキストでのみ発生します。たとえば、ManualPaymentMadeEventは注文コンテキストで発生し、配送コンテキストのイベントリスターもそれを消費し、配送開始のトリガーと見なします。

私は、データベースごとのユーザー（オラクル用語）をコンテキストごとに使用することを好みます。出荷コンテキストのshipping.domain_eventsと注文コンテキストのordering.domain_events。

axon-framework のスキーマは次のとおりです。役立つかもしれません

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