Event Sourcing: требования и впечатления

Наверняка вы уже слышали об этом паттерне. Коротко говоря, в Event Sourcing состояние приложения определяется последовательностью событий (events), а не просто текущим состоянием данных. Каждое изменение сохраняется как неизменяемое событие. Можно восстановить экземпляр процесса, получить информацию о поведении системы, восстановить данные, если отследить или выполнить связанные события.

Данные не перезаписываются, а дополняются новыми событиями. Например, хранится только текущий баланс счета, и при необходимости по цепочке событий можно восстановить баланс на любом шаге изменений счета.

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

С точки зрения состава требований понадобятся:
📍структура события – состав атрибутов, обязательность, порядок заполнения;
📍типы событий – сама модель того, что должно сохраняться (OrderCreated, OrderCompleted и пр.);
📍место и политики хранения (где и как долго хранить. Этот и следующий пункт больше к СА или архитектору);
📍механизмы доставки и воспроизведения.

В части структуры и типов в моем случае сложным оказалось перекладывание бизнес-понимания шагов процесса на события в системе. За шагом вида "подать заявку" прячутся десятки взаимодействий между сервисами: для валидации данных, проверок дубликатов, обработки исключений и пр. Это связать с процессом особенно непросто, когда сам процесс не представлен в формате автономных задач с понятными входом и выходом. Здесь как раз вспомнился BPMN c его токенами. Звучит занудно, но не могу удержаться 🙈 Адекватную модель процесса гораздо проще переложить на архитектурное решение, чем наоборот – подстраивать одно под другое.

📚По традиции делюсь материалами:
Гайд по эвент-сорсингу
Знакомимся с Event Sourcing

#что_почитать #инструменты