CQRS — это не команды и хендлеры. Главный миф на собесе

CQRS на собесе — классика, на которой тормозят даже опытные ребята. Разбираем по делу: три варианта реализации от простого к сложному, главный миф, который портит жизнь, и реальные кейсы из e-commerce и финтеха. Никакого «вот вам диаграмма из википедии». Что внутри: — Почему половина «CQRS-проектов» на самом деле никакой не CQRS — Три уровня реализации: от разделения папок до двух разных баз — Синхронная и асинхронная синхронизация, eventual consistency и как её прожить без багрепортов — Когда CQRS реально нужен, а когда ты усложняешь себе жизнь без причины — FAQ по паттерну: что если в query нужна запись, может ли command возвращать значение Разбор DDD:    • Domain-Driven Design | Просто о сложном   Текстовую шпаргалку к этому ролику кину в Telegram: https://t.me/+46tCClyAizozYWIy — DevDad — готовлю backend-разработчиков (C#/.NET, Java, Go) до оффера. Если собираешься на собесы в ближайшее время — заходи: https://clck.ru/3TBtHk — Таймкоды: 00:00 Собесный вопрос, на котором многие замирают 00:57 Зачем вообще разделять чтение и запись (Twitter, e-commerce) 02:23 Commands и Queries: в чём реальная разница 03:18 Идея CQRS за 30 секунд 04:47 Вариант 1: разделение на уровне приложения 06:06 Вариант 2: две схемы в одной базе 07:02 Синхронная и асинхронная синхронизация 09:51 Вариант 3: две разные базы (Postgres + Elastic, Clickhouse) 11:15 Главный миф: CQRS — это не команды и хендлеры 13:05 Кейс 1: e-commerce с каталогом на 100к товаров 14:35 Кейс 2: финтех с отчётами через Clickhouse 15:31 Когда CQRS — плохая идея 16:25 Как не облажаться с eventual consistency в UX 17:50 FAQ: запись в query и возврат из command #cqrs #архитектура #бэкенд #собеседование #программирование #микросервисы #backend