Event Sourcing
Какие проблемы создает и решает Event Sourcing? Технические нюансы реализации.
Есть некая система с каким-то хранилищем, в котором мы храним состояние объекта. И тут совершенно неважно, реляционное оно или нет.
Важно понять, что же именно изменилось в объектной модели, особенно если данных очень много (большое количество связанных таблиц и строк).
Даже если мы разобрались, что изменилось, всегда возникает не менее сложный вопрос – а почему, собственно, эти изменения произошли. Полагаться на колонки «кто изменил», «когда изменил», конечно, можно, но как правило это вызывает кучу лишних действий, а порой и встреч.
В хранении состояния нет ничего плохого, но есть определенные сложности: 1⃣ Причину изменения сложно понять. 2⃣ Жесткая связь клиент-хранилище-формат. 3⃣ Невоспроизводимость для отладки. 4⃣ Необходимость «втягивания» данных.
Для решения этих проблем и был разработан шаблон Event Sourcing.
Event Sourcing – это моделирование информации об активности в домене в виде обособленных событий. Каждое событие также является доменным объектом.
Важно не путать «команды» и «события».
Команда – это запрос в будущее, надежда на то, что оно наступит.
Событие – это факт того, что будущее наступило. Событие нельзя отменить, на него можно только реагировать или не реагировать.
Читая события, обычно уже можно сделать какие-то внятные выводы о целях и задачах конкретного домена.
В первых темах про микросервисы мы затрагивали такое понятие как агрегатор.
Агрегатор – кластер связанных объектов, который мы воспринимаем как один логический объект. Как правило, мы сохраняем весь агрегатор в базу данных и читаем его целиком, особенно если хотим изменить его.
Также важно понимать, что агрегат хранит в себе все свое состояние, и все характеристики должны быть согласованы.
Давайте приведем пример возможных событий для агрегата какого-то товара в интернет-магазине:
1. Товар создан. 2. Товару назначена цена. 3. Товару добавлен цвет. 4. Товар отправлен на модерацию. 5. Товар опубликован.
И когда мы хотим получить актуальное состояние товара, мы должны получить все его события от самого раннего события до самого последнего, в данном случае от 1 до 5.
И тут сразу возникает вопрос: а что если изменений слишком много? Например, 500-1000 изменений?
В шаблоне Event Sourcing такие задачи решаются с помощью Snapshots.
По сути, это некоторый слепок состояния через N количество событий. Например, если у нас уже случилось 100 событий, мы делаем Snapshot.
Все следующие события будут опираться на то, что мы зафиксировали в Snapshot. В данном подходе важно, что после создания Snapshot факты, которые попали в него, не удаляются.
Слепки можно удалять, менять и так далее. Они нужны лишь для того, чтобы быстрее получать необходимую информацию, но факты (события) удалять нельзя.
Откуда же брать события?
Для выявления и моделирования событий используется техника Event Storming.
Как правило, собираются доменные эксперты, пользователи и бизнес-эксперты, которые вместе начинают думать, а что же должно происходить в нашей новой системе.
Все накидывают свои идеи и решения очень грубыми мазками.
Далее происходит сортировка, дедубликация событий и логическая группировка по ответственности.
Задачи Event Storming: ✔️ определить ключевые события для основных бизнес-процессов, ✔️ проработать негативные сценарии (например, отмена), ✔️ постараться сделать так, чтобы в рамках одного сервиса жил только один агрегат, ✔️ опираться на факты.
Реализация
Для реализации Event Sourcing не требуется каких-то отдельных фреймворков. События – это обычные классы или структуры.
Для хранения событий подойдет любая база данных, которая не диктует жестких правил по схемам хранения.
Плюсы Event Storming: ✅ хорошее отображение бизнес-процесса, ✅ явное описание причин изменений, ✅ возможность воспроизведения события для отладки, ✅ система изначально готова к распределенной работе, ✅ готовый источник данных для аналитических систем.
В следующем посте Command & Query Responsibility
Мой канал - https://t.me/carbonka
