Во многих системах после изменения старое состояние исчезает. Баланс стал другим, статус заказа поменялся, данные клиента обновились — и база хранит только результат.
Но иногда бизнесу важен не только итог. Важно понимать, какие события привели к нему, в каком порядке и почему.
Какую проблему мы решаем
Event Sourcing хранит не только текущее состояние объекта, а последовательность событий: заказ создан, позиция добавлена, оплата подтверждена, адрес изменён.
Текущее состояние можно получить, последовательно применив эти события. В практических системах для ускорения часто используются snapshots и отдельные модели чтения.
Главное отличие — история становится частью основной модели данных, а не вторичным журналом.
Что получает бизнес
Главная ценность — объяснимость важных изменений.
Если нужно разобраться, почему баланс, статус или договорное состояние оказалось именно таким, у компании есть не только текущая цифра, но и цепочка событий, которая её сформировала.
Это может уменьшать стоимость расследований и разбирательств, а также открывать новые сценарии: пересчитать состояние по новым правилам, построить новую аналитику на старой истории или восстановить производное представление данных.
Но выгода появляется только тогда, когда история действительно имеет бизнес-ценность. Хранить каждое изменение «на всякий случай» — дорогой способ получить сложную систему.
Что получает команда
Команда получает полный журнал доменных изменений и возможность строить разные представления из одного потока событий.
Но меняется сам способ проектирования. Нужно версионировать события, понимать, что старые события нельзя бездумно переписывать, уметь восстанавливать состояние и поддерживать проекции.
Отладка становится одновременно сильнее и сложнее: история есть, но её нужно правильно интерпретировать.
Что получает клиент
Клиент может получить более прозрачный продукт: историю операций, понятное объяснение изменений, возможность восстановить последовательность действий.
Но сама технология клиенту не нужна. Если бизнес не превращает историю в понятную пользу, Event Sourcing остаётся внутренней сложностью.
Чем мы за это платим
Цена высокая: сложнее модель данных, миграции, тестирование, хранение и обучение команды.
Особенно болезненна эволюция событий. Код меняется, а события пятилетней давности должны оставаться интерпретируемыми.
Появляется и eventual consistency, если модели чтения обновляются асинхронно.
Когда Event Sourcing не нужен
Если бизнесу достаточно текущего состояния и обычного audit log, Event Sourcing почти наверняка избыточен.
Он особенно плохо окупается в простом CRUD, где история не создаёт дополнительной ценности и не влияет на принятие решений.
Что стоит спросить перед решением
- Нужна ли бизнесу полная история причин изменения состояния?
- Будем ли мы реально пересчитывать или переиспользовать эту историю?
- Достаточно ли обычного audit log?
- Готова ли команда поддерживать версии событий годами?
- Как быстро должны обновляться модели чтения?
В итоге
Event Sourcing превращает историю из побочного лога в источник истины.
Для бизнеса это оправдано, когда вопрос «как мы получили это состояние?» достаточно важен, чтобы платить за более сложную модель данных и её долгую поддержку.