Когда стоит вводить event sourcing, и какие риски и издержки это добавляет команде? Обсудите компромиссы, риски и критерии выбора — единственного правильного решения может не быть?

Короткий ответ

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

Как это работает подробнее

Вместо обновления строки до нового значения система добавляет запись о событии; текущее состояние — результат применения (reduce) всех событий сущности по порядку, получают через проекции, что сближает event sourcing с CQRS.

Event sourcing даёт сильную аудируемость и возможность восстановления состояния на любой момент, но многократно увеличивает сложность разработки (события, проекции, миграция схем) и требует зрелости команды — ошибки в дизайне событий сложно исправить, так как события неизменяемы. Обычное хранение текущего состояния с отдельным audit log проще в поддержке и покрывает большинство практических целей, но не даёт «бесплатного» восстановления состояния на произвольный момент. Критерий выбора — реальная потребность в истории и replay, и готовность нести долгосрочные издержки поддержки схемы событий.

Что использовать на практике

• Практика. Оправданные случаи — финансовый учёт с требованием полной аудируемой истории, сложные бизнес-процессы, где важно понять «как мы пришли к этому состоянию»; для обычных CRUD-сущностей это создаёт сложность без соразмерной выгоды.

Подводные камни

• Риск. Вводить event sourcing целиком для всей системы вместо точечного применения к нужным агрегатам; не продумывать эволюцию схемы событий — старые события навсегда остаются в старом формате.