Когда Event Sourcing и полный CQRS применять не стоит, и что делать вместо этого?

Вопрос про инженерную зрелость: ответ «зависит» не годится, нужны конкретные условия и цена.

Когда не стоит:

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

Цена, о которой забывают: версионирование событий — постоянная работа; проекции отстают и иногда расходятся с журналом, отладка таких расхождений тяжела; запросы по текущему состоянию требуют проекций; миграции превращаются в апкастинг.

Когда оправдано: история и аудит — бизнес-требование (финансы, учёт, страхование), нужно восстановление состояния на момент, сложные процессы с множеством реакций на события.

Как вводить: сначала простой CQRS внутри приложения; если нужно — отдельная модель чтения через outbox или CDC; event sourcing — только для отдельного ограниченного контекста, где он окупается, а не для всей системы. Часто историю закрывает обычная аудит-таблица или журнал изменений.