Я читал об источниках событий, и хотя я нашел это вполне естественным подходом к нескольким проблемам, я не совсем понял, как хранить события на практике.Хранение событий при использовании Event Sourcing
Поиск немного в Интернете Я нашел this article от Vaughn Vernon, говорящий о простом подходе к хранению агрегатов в DDD. Хотя речь идет не только о поиске источников событий, он предназначен для хранения доменных событий с использованием PostgreSQL.
В своем подходе у нас есть стол Events с одним id и полем JSON data. Это дает большую свободу, поскольку мы можем хранить любые данные JSON и, следовательно, мы можем хранить различные события.
Но имея всех событий соответствующих всех агрегатов в одной таблице, делаешь меня немного беспокоит.
Итак, когда мы храним события для использования источников событий, как мы должны действовать? Я вижу три варианта:
Следуя идее, используемой для событий домена в статье, и храните все внутри одной таблицы.
Создайте одну таблицу за каждое событие. Недостатком здесь является то, что нам нужно отслеживать события для каждого агрегата, и для каждого агрегата могут быть различные события. Таким образом, это легко приведет к огромному количеству таблиц.
Создайте одну таблицу для каждого агрегата и сохраните все события для этого агрегата. Хотя в итоге мы сталкиваемся с различными событиями, собранными в одной таблице, все они связаны с одним и тем же агрегатом.
Какой из этих трех вариантов был бы более разумным? Если нет, то каким будет правильный способ хранения событий при использовании источников событий?