Event Sourcing — это паттерн, при котором все изменения состояния системы сохраняются как последовательность событий (event log). Вместо того чтобы хранить только текущее состояние сущности (например, заказ с полем
status), вы записываете каждое событие: OrderCreated, PaymentReceived, OrderShipped, OrderCancelled. Текущее состояние вычисляется путём повторного применения всех событий к начальному состоянию (или через снимки состояния + дельта событий).Ключевые преимущества:
Полный аудит – есть журнал всех изменений, можно ответить на вопрос «кто и когда изменил это поле».
Восстановление на любой момент времени – можно «перемотать» состояние к любой временной точке, повторно применив события до нужного момента.
Отладка и анализ – можно воспроизвести сценарий на тестовом окружении, чтобы найти причину ошибки.
Гибкость – можно строить разные read-модели (CQRS) на основе одного и того же потока событий без изменения источника.
Почему не подходят другие варианты:
A (CQRS) – разделяет команды и запросы, но может работать без Event Sourcing (например, на основе обычной БД).
B (Saga) – паттерн для распределённых транзакций, не про хранение истории.
D (Strangler Fig) – стратегия замены монолита на микросервисы, не имеет отношения к хранению изменений.
Реальный пример:
В банковских системах Event Sourcing используется для хранения всех транзакций по счёту. Это позволяет восстановить баланс на любую дату и обеспечить детальный аудит для регулятора.
Что должен зафиксировать аналитик:
«Для сущностей, требующих полного аудита и восстановления состояния на любой момент времени, использовать Event Sourcing».
«Хранить события в неизменяемом хранилище (например, Kafka, Event Store)».
«Реализовать проекции для построения текущего состояния».
Вывод: Event Sourcing — это стандарт для систем, где важна история изменений и возможность отката/аудита. Аналитик, закладывающий этот паттерн в требования, даёт команде мощный инструмент для обеспечения прозрачности и надёжности.