Event Sourcing и CQRS
(продолжение предыдущего поста)

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

Как работает Event Sourcing

* Вместо сохранения только конечного состояния (например, «баланс = 200 $») система записывает каждое событие («Добавлено 100 $», «Снято 50 $» и т. д.).
* Текущее состояние вычисляется путём воспроизведения прошлых событий.
* Система работает как хронологическая книга учёта — прозрачная, поддающаяся аудиту и воспроизводимая.

Компоненты

* Хранилище событий — сохраняет все события в хронологическом порядке (только добавление).
* Обработчики команд — обрабатывают поступающие действия и создают новые события.
* Процессоры событий — реагируют на сохранённые события, обновляют проекции или запускают побочные эффекты.
* Проекции — представляют оптимизированные для чтения представления, построенные на основе воспроизведённых событий.

Поток данных

Команда → Создание события → Сохранение события → Обновление проекций → Перестроение состояния по требованию

Преимущества

* Полный аудит и возможность «путешествовать во времени» среди данных.
* Простота отладки и воспроизведения истории системы.
* Естественная совместимость с распределёнными и управляемыми событиями системами.
* Поддержка реактивных и асинхронных рабочих процессов.

Недостатки

* Объём хранилища может быстро расти.
* Сложная логика версионирования событий и их воспроизведения.
* Требуется тщательное управление проекциями и согласованностью.

Как работает CQRS

* Расшифровывается как *разделение ответственности команд и запросов* (Command Query Responsibility Segregation).
* Разделяет систему на две части:
* Сторона команд — обрабатывает операции записи (создание, обновление, удаление).
* Сторона запросов — обрабатывает операции чтения (эффективное получение данных).
* Каждая часть может масштабироваться, моделироваться и оптимизироваться независимо.

Преимущества

* Оптимизированная производительность для операций чтения и записи.
* Лучшее разделение ответственности и более чистый дизайн.
* Проще развивать модели чтения, не затрагивая операции записи.
* Хорошо сочетается с Event Sourcing для создания проекций.

Недостатки

* Больше компонентов — повышается сложность архитектуры.
* Согласованность между сторонами чтения и записи достигается не сразу (eventual consistency).
* Требуются надёжные механизмы обмена сообщениями и синхронизации.

Совместный поток (Event Sourcing + CQRS)

Команда → Генерация события → Сохранение события → Обновление проекции → Чтение запроса из проекции

Когда применять

* Системы, требующие аудита, возможности воспроизведения или управляемые событиями рабочие процессы.
* Приложения, где операций чтения значительно больше, чем операций записи (например, аналитические панели).
* Финансовые системы, бухгалтерские книги, CRM, системы отслеживания логистики и платформы IoT.