Паттерн Event Sourcing (источники событий)
(продолжение предыдущего поста)

Event Sourcing (источники событий) — это архитектурный паттерн, при котором изменения состояния системы сохраняются в виде последовательного лога событий (событийного журнала), а не напрямую в виде состояния сущностей. Этот подход позволяет воссоздать текущее или историческое состояние системы, воспроизводя события в хронологическом порядке.

Разберём принцип работы по изображению:

1. App (Приложение): инициирует операции (Operations), которые преобразуются в события.

2. Event Store (Хранилище событий):
* служит центральным хранилищем, где последовательно сохраняются все события, происходящие в системе;
* события хранятся в неизменяемом (immutable) виде — их нельзя удалить или изменить, только добавить новые;
* это "источник истины" для всей системы.

3. Event Store Consumer (Потребитель хранилища событий):
* считывает события из хранилища (Consume Event);
* применяет события для формирования текущего состояния системы;
* обновляет Current State DB (БД текущего состояния) — оптимизированную базу данных для быстрого доступа к актуальному состоянию сущностей.

4. Current State DB (БД текущего состояния):
* содержит актуальное состояние системы, сформированное на основе событий;
* используется для быстрых операций чтения (например, отображения данных пользователю).

5. Replay Processor (Процессор воспроизведения):
* позволяет "перепроиграть" события из хранилища для воссоздания состояния системы на любой момент времени (Point in Time — PIT);
* полезен для отката изменений, аудита, восстановления после сбоев или анализа истории изменений.

6. Point in Time DB (БД момента времени):
* хранит состояния системы на определённые моменты времени (снимки состояния);
* позволяет быстро получить состояние системы "на дату", без необходимости полного перебора событий.

Ключевые особенности Event Sourcing:
* Децентрализованное изменение и чтение данных — события могут обрабатываться асинхронно разными компонентами системы.
* Аудит и история изменений — полный лог событий позволяет отследить, кто, когда и какие изменения вносил.
* Возможность отката — при ошибках или необходимости можно "откатить" систему до предыдущего корректного состояния.
* Масштабируемость — событийный лог легко горизонтально масштабируется.
* Сочетание с CQRS — часто используется вместе с паттерном CQRS (Command Query Responsibility Segregation) для разделения команд (изменений) и запросов (чтения).

Примеры применения:
* финансовые системы (где важна история транзакций);
* системы электронной коммерции (отслеживание изменений корзины, заказов);
* CRM-системы (логирование изменений статусов клиентов);
* игровые платформы (сохранение прогресса игрока).

В итоге Event Sourcing смещает фокус с хранения состояния на хранение изменений (событий), что делает систему более гибкой, прозрачной и устойчивой к ошибкам. Однако этот паттерн требует дополнительных ресурсов на моделирование и обработку событий.