@BashkaMen
C# программист

Можете дать пару ответов про Event Sourcing?

Здравствуйте, заинтересовала меня модель Event sourcing, и в качестве эксперимента накидал Todo-шку с использованием этого подхода. Я бы хотел чтоб бы вы посмотрели на реализация и возможно предложили как по другому реализовать евенты, их мутацию, и вообще доставание агрегата. Скажу сразу что интересует только вариант в одной базе, а про разделение на модели чтения и записи я знаю.

https://github.com/BashkaMen/SimpleEventSourcing-Todo

Так же есть пару конкретных вопросов:
1) Есть команда и событие создание Todo припустим со временем добавится ещё что то, припустим поле description, я должен модифицировать евент создания или создать event создания 2.0? Если создавать новый, то не будет ли со временем по пару десятков евентов, которые существуют только чтоб поддерживать старые евенты?
2) Если я нашел баг, который не верно создавал евенты какие варианты это исправить? Ведь евенты по идее удалять нельзя.
3) Когда я захотел достать из базы все Todo я в начале искал все евенты по типу "TodoCreated", взял их AggregateId и потом пошел доставать сами агрегаты это верный подход?
FNSb0Li.png
  • Вопрос задан
  • 145 просмотров
Решения вопроса 1
Robur
@Robur
Знаю больше чем это необходимо
1) решается по разному, в идеале - все созданные ивенты немутабельные и лежат в базе вечно. Это позволяет избежать кучи проблем. То есть при изменении надо создавать event v2. Но - это только на несовместимые изменение, добавление поля обычно можно сделать совместимым. Код который будет работать с этим полем будет работать должен учитывать что description может быть а может и нет. Старый код который работал без description - будет работать как работал и останется без изменений.

Чаще всего достаточно добавить новые ивенты для новых вещей. Например раньше были аггрегаты без description, теперь появилось это поле, это значит что появились какие-то операции над этим полем и вы можете добавить ивент DescriptionAdded вместо того чтобы менять event создания.
Однако я встречал статьи о том что люди переписывали историю ивентов для поддержки нового формата - возможно в каких-то случаях это действительно более оптимально. Не делал, подводных камней не знаю.

2) создавать "исправляющие" ивенты. например ваш баг добавил всем к дню рождения лишний день при создании пользователей - создаете еще ивенты которые отнимают этот день.

3) Зависиот от реализации стора, но читать все ивенты из стора чтобы их пофильтровать в памяти в любом случае подход так себе. Реальное приложение при таком подходе загнется крайне быстро.
Для таких вещей используются проекции - когда из ивентов вы строите нужную модель в какой-то удобной форме и делаете запросы туда.

например храните в SQL список todo на текущий момент, со всеми ивентами и просто делаете select * from todo.
ну или хотя бы делаете таблицу со всеми create ивентами чтобы читать не 50 миллионов и фильтровать а сразу получить список аггрегатов одним запросом.
Тут eventual consisntency встает в полный рост.
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы