Как организовать event sourcing с очередями сообщений

Event sourcing хранит состояние сущности как последовательность неизменяемых событий, а не только как текущую строку в таблице. Очередь сообщений может доставлять эти события другим сервисам и проекциям, но сама очередь не всегда является постоянным источником истины: для восстановления состояния нужен надёжный журнал событий с версиями, снимками состояния и правилами изменения схемы.

Что такое event sourcing

При event sourcing источником истины является журнал событий. Вместо хранения только текущего состояния заказа система сохраняет последовательность фактов: OrderCreated, ItemAdded, PaymentAuthorized, OrderCancelled. Текущее состояние восстанавливается применением событий по порядку.

Order events:
1. OrderCreated
2. ItemAdded
3. ItemAdded
4. PaymentAuthorized
5. OrderCompleted

Event store и очередь сообщений

Event store — постоянное хранилище, где события записываются с гарантией порядка и версии для конкретной сущности. Очередь или поток сообщений распространяет эти события к другим компонентам: проекциям для чтения, аналитике, уведомлениям и интеграциям.

Command
  |
Aggregate validates business rules
  |
Append event to event store
  |
Publish event
  |
+----------------------------+
|                            |
Read model projector      External integrations
  |
Read database

Оптимистичная блокировка

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

event stream:
  aggregate_id: order-42
  expected_version: 5
  new_event: ItemAdded

Проекции

Проекция читает события и строит удобную модель для конкретного запроса: список заказов пользователя, отчёт по продажам или остатки товаров. Проекции можно пересобрать, перечитав журнал событий. Между записью события и обновлением проекции обычно есть небольшая задержка.

Снимки состояния

Если у сущности очень длинная история, восстановление состояния через все события становится дорогим. Тогда периодически сохраняют снимок текущего состояния и при загрузке применяют только события после него.

Версии событий

События могут жить годами, поэтому их схему нельзя менять без плана. Нужно добавлять версию события, сохранять обратную совместимость, использовать преобразователи старых форматов и не удалять поля резко, пока есть старые получатели.

Сложности

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

Как ответить на собеседовании

Event sourcing хранит не только текущее состояние, а последовательность доменных событий. Команда проверяется агрегатом, новое событие добавляется в постоянный журнал с ожидаемой версией, затем распространяется через очередь к проекциям и интеграциям. Очередь не всегда заменяет event store: для восстановления нужны долговременное хранение, порядок событий, версии и снимки состояния. Подход оправдан для сложного домена с требованиями к аудиту и восстановлению истории, но избыточен для простого CRUD.

Как организовать event sourcing с очередями сообщений?