Что такое CQRS? Когда его применять?
Подробный ответ
Идея CQRS
В обычном CRUD одна модель часто используется и для чтения, и для записи. CQRS разделяет эти обязанности: command меняет состояние и не возвращает сложные данные, а query только читает данные и не имеет побочных эффектов.
Command
|
Write model
|
Primary database
|
Domain event
|
Read model projector
|
Read database / materialized view
|
QueryПример
Команда CreateOrder проверяет бизнес-правила, создаёт заказ и публикует событие OrderCreated. Read model строит удобное представление для списка заказов, дашборда или отчёта. Read-таблица может быть денормализована и оптимизирована именно для быстрых запросов.
Преимущества
можно независимо масштабировать read и write нагрузку;
read model можно оптимизировать под конкретные экраны и запросы;
сложные бизнес-правила не смешиваются с кодом чтения;
удобно сочетать с event-driven архитектурой и event sourcing.
Недостатки
появляется eventual consistency между write и read model;
нужны обработка событий, идемпотентность, retries и мониторинг lag;
сложнее тестирование, отладка и поддержка схем данных.
Когда использовать
CQRS имеет смысл при сложном домене, большом перекосе в сторону чтения, сложных отчётах, отдельных read-представлениях или потребности независимо масштабировать команды и запросы. Для небольшого CRUD-приложения чаще достаточно обычной модели и хороших индексов.
Как ответить на собеседовании
CQRS разделяет write model и read model: commands меняют состояние, queries только читают. Это помогает отдельно масштабировать чтение и оптимизировать read-представления, но добавляет eventual consistency и сложность обработки событий. Я не использую CQRS для простого CRUD без явной причины.
Оцени свой прогресс