Схема реляционной базы данных для поиска событий

Я пытаюсь сохранить события домена в базе данных postgres. Я не уверен во многих вещах, и я не хочу позже изменять эту структуру, поэтому я ищу руководство от людей, которые имеют опыт работы с источниками событий. В настоящее время у меня есть следующая таблица:

domain events
    version - or event id, integer sequence, helps to maintain order by replays
    type - event type, probably classname with namespace
    aggregate - aggregate id, probably random string for each aggregate
    timestamp - when the event occured
    promoter - the promoter of the event, probably user id
    details - json encoded data about the properties

В чем я не уверен

Стоит ли хранить промоутер доменного события?
Это может помочь найти скомпрометированную учетную запись по нарушениям безопасности, но я не знаю, что хранить, например, с помощью CRONjob.В каком формате я должен хранить тип события?
Должен ли я добавить таблицу с типами событий, или имена классов достаточно?
Должен ли я добавить группы событий?Я запутался в определении ограниченного контекста. Насколько я знаю, каждый агрегат может иметь несколько ограниченных контекстов, поэтому я могу использовать различные аспекты одного агрегата в нескольких модулях. Это звучит хорошо, так как, например, учетные записи могут быть связаны со многими вещами, включая аутентификацию, авторизацию, профиль пользователя, сообщения пользователя, пользовательские контракты и так далее ...
В чем я не уверен, что у доменного события может быть несколько ограниченных контекстов или только один, поэтому я должен также хранить контексты событий? (для случаев, когда я хочу воспроизвести события, связанные с одним контекстом)
Как реализовать так много свойств в одном классе агрегатов, я должен использовать какую-то композицию?

Ответы на вопрос(1)

Ваш ответ на вопрос