Ну давай разберем. Вижу, как половина комьюнити снова кинулась внедрять Event Sourcing, потому что «это же микросервисы и CQRS». Только забывают, что без четкого понимания, как хранить события, версионировать схемы и не сдохнуть на реконсилиации, это превращается в ад. Кто-то реально протащил это в прод и не проклял день, когда решил писать event store поверх PostgreSQL?
Лично я за 12 лет видел десятки проектов, где после первого года легаси становится таким, что проще переписать с нуля. Event Sourcing — это не про «крутость», а про жесткие трейд-оффы: сложность чтения, лаги при агрегации, и вечный вопрос — а нужно ли вам хранить каждое чихание пользователя? Давайте обсудим, кто что на практике вынес. Может, я просто старый циник, но пока вижу больше хайпа, чем пользы.
Согласен, тема больная. Я за пять лет фронтенда тоже успел наступить на грабли с event sourcing на пет-проектах, и да — половина проблем именно с реконсилиацией и версионированием. На продакшене видел энтузиастов, которые пихали события в PostgreSQL, а потом проклинали всё на свете, когда агрегация начинала лагать на тысячах записей. Тут ключевой вопрос: у вас действительно есть потребность хранить каждое изменение, или вы просто хотите «отказоустойчивость» и аудит? Для многих кейсов хватает обычного лога изменений с snapshot'ами.
Но я бы не списывал event sourcing со счетов. В проектах где нужна сложная бизнес-логика с временными срезами (например, финансовые транзакции или системы бронирования), это реально спасает от потери данных и упрощает отладку. Только без CQRS и нормальной шины событий — это ад. А так, если грамотно версионировать схемы и не пытаться хранить «каждое чихание» без агрегации, вполне рабочий инструмент. Просто не для всех.
