Если Event sourcing для вас новинка, то перед дальнейшим прочтением рекомендую изучить хотя бы некоторые видео из списка ниже:
- Ануар Нурмаканов — Event Sourcing и CQRS на конкретном примере
- Яков Повар — Введение в Event sourcing
- Event Sourcing You are doing it wrong by David Schmitz – мне нравится тем, что описываются различные вариации реализации
- Event sourcing meetup with Alexey Zimarev and Greg Young – классическая презентация от Greg Young (во многом популяризатора термина)
- Opening Keynote: Greg Young - Stop Over-Engenering
- Designing Events-First Microservices
- Go Back to the Future with Event Sourcing and CQRS
- Event-Driven Architectures for Spring Developers
- Event Sourcing - what could possibly go wrong? • Andrzej Ludwikowski • Devoxx Poland 2021
- Building Event-Driven Microservices with Event Sourcing and CQRS - Lidan Hifi
- The Power of Event-Driven Systems without Burning your Hands or Budgets • Allard Buijze • GOTO 2020
Краткое описание
Event sourcing – это архитектурный принцип. В разных интерпретациях он немного отличается. Введем определения, чтобы говорить на одном языке:
- Для изменения данных принимаются
команды. Например, RegisterUser. Команда может ответить ошибкой, если посчитает, что невозможно выполнить. Команда формирует 1+событий. События– это свершившийся факт. Они хранятся отдельно, например, в какой-нибудь табличке в базе. Или в Kafka. Например, UserRegistered. Назовем хранилищеevent store.Агрегат– центральный термин транзакционности. Каждое событие привязано к нему. Например,User(GUID="...."). Видно, что обычно у агрегата есть тип (user) и id (guid).- При чтении данных иногда в памяти создают агрегат, прокручивают в нем события – таким образом получают текущее состояние агрегата – и отдают его в нужной форме. Это называется
живая проекция. Звучит на первый взгляд странно, но при размере агрегата до 20 событий работает практически моментально. - А иногда используется обычная БД, оптимизированная под чтение. Ее называют
проекцией. Потенциально, таких баз может быть несколько (например, Elasticsearch для полнотекстового поиска и Postgres для обычных запросов). Обычно одну из них называютосновной проекцией. - Чтобы сделать проекции есть обработчики, которые слушают появление новых событий. Их называют
проекторы. - Если проекторы работают синхронно с добавлением новых событий, то это
встроенные проекторы(inline). Иначе этоасинхронные проекторы. - Для сайд-эффектов (общение с внешними системами, создание вторичных событий) есть отдельный вид обработчиков –
реакторы.
Проекции можно разделить на 3 типа:
- встроенные (inline) проекции - запускается как часть механизма получения команд
- асинхронные (async) проекции - работают как фоновый процесс (а значит с задержками)
- живые (live) проекции - не используется дополнительное храналище, вычисляются динамически из событий
Event sourcing замечательно сочетается с “CQRS”. По сути event sourcing – это продолжение CQRS внутри бекэнд части приложения, включая БД. Поэтому их иногда не различают, но это разные вещи.
Кто-то внедряет event sourcing в части приложения, кто-то полностью.
Отмечу, что к схеме выше есть множество вариаций, т.к. это принцип, а даже не определенная архитектура.
Примеры реализаций
Коммерческие движки:
Open source движки:
- https://www.sequent.io/
- https://railseventstore.org/
- https://github.com/digital-fabric/ever
- https://github.com/envato/event_sourcery
- https://martendb.io/events/
- https://github.com/commanded/commanded / https://github.com/commanded/eventstore
- https://github.com/cultureamp/kestrel
- https://github.com/cultureamp/event_framework
- https://occurrent.org/
Open source шаблоны приложений:
- https://github.com/isalevine/event-sourcing-user-app
- https://github.com/nicusX/kotlin-event-sourcing-example
1C
Не сразу очевидно, что 1С – это самое популярное event sourcing решение. Оно и не мудрено – там идет интенсивная работа с людьми и деньгами, а значит нужна история.
Журнал документов – event store. Регистры – проекции. И т.п.