Что такое CQRS? Command Query Responsibility Segregation

Определение CQRS

CQRS означает, что Commands изменяют состояние через write-модель, а Queries читают модели, построенные под конкретные вопросы. Сторона записи отвечает за решения и инварианты. Сторона чтения отвечает за формы данных для UI, поиска, аналитики или операций.

Интерес к запросу «CQRS» обычно включает три вопроса: что означает CQRS, чем он отличается от Event Sourcing и когда паттерн полезнее обычного CRUD.

• Commands выражают бизнес-намерение на стороне записи
• Queries используют отдельные read models или Projections
• Инварианты остаются в Aggregates, а не в Projection handlers
• Eventual consistency — явный tradeoff, а не случайность

Когда CQRS окупается

CQRS оправдан, когда форма записи отражает сложные решения, а чтение требует другого представления: плоских списков, полнотекстового поиска, аналитики, денормализованных карточек или данных из нескольких агрегатов. Раздельные модели позволяют защищать домен, не заставляя интерфейс восстанавливать удобное представление из сложного графа объектов.

Для простого CRUD с одинаковыми формами чтения и записи CQRS может добавить лишние типы, обработчики и точки отказа. Используйте его для конкретной сложности, а не как обязательный атрибут DDD.

• Сложные инварианты на стороне записи
• Несколько существенно разных моделей чтения
• Высокая или независимая нагрузка на чтение
• Необходимость объединять данные разных границ
• Разные требования к масштабированию и хранению

Путь команды

Команда выражает намерение и содержит данные, необходимые для решения. Обработчик определяет адресата, загружает агрегат, вызывает доменное поведение и сохраняет результат. Агрегат принимает или отклоняет намерение на основании текущего состояния и инвариантов.

Успешное решение создаёт доменное событие. Обработчик не должен дублировать правила агрегата в application layer. Команда может завершиться синхронным подтверждением принятия, но это не означает, что все модели чтения уже обновлены.

Проекции и модели чтения

Проекция строит представление под конкретный вопрос: OrderSummary, TicketBoard, CustomerBalance. Она обрабатывает события и обновляет структуру, удобную для запроса. В одной системе может быть несколько проекций одного факта — для UI, поиска, отчётности или интеграции.

Храните в модели чтения только необходимые данные и проектируйте её контракт от потребителя. Она не должна становиться вторым доменным агрегатом: проекция отображает факты, но не принимает бизнес-решения.

Согласованность и ожидания пользователя

При асинхронном обновлении модели чтения возникает eventual consistency: команда уже принята, а новое состояние ещё не видно в запросе. Это нужно учитывать в интерфейсе и API. Можно вернуть идентификатор операции, показать локально подтверждённое изменение, дождаться определённой версии проекции или явно отобразить статус обработки.

Не обещайте read-your-writes, если архитектура его не обеспечивает. Для критичных сценариев допустима синхронная проекция или чтение подтверждения из write side, но такое решение должно быть осознанным.

Идемпотентность и порядок событий

Обработчик проекции должен безопасно переживать повторную доставку. Храните обработанную позицию, версию события или уникальный идентификатор и не применяйте одно изменение дважды. Если порядок важен, определите его границу: глобальный порядок обычно дорог и не нужен, а порядок событий одного агрегата можно контролировать версией.

Позднее событие не должно незаметно перезаписывать более новое состояние. Правило разрешения конфликтов является частью дизайна конкретной проекции.

Перестроение и версия проекции

Проекции являются производными данными, поэтому их желательно уметь перестраивать из надёжного источника событий или другого журнала изменений. При изменении схемы создайте новую версию, заполните её параллельно и переключите запросы после проверки, вместо рискованного изменения рабочей таблицы.

Если полной истории событий нет, заранее определите источник backfill: snapshot write-модели, журнал интеграционных событий или миграционный запрос. CQRS не гарантирует автоматическую перестройку без такого источника.

CQRS и Event Sourcing — разные решения

CQRS разделяет обязанности команд и запросов. Event Sourcing хранит состояние как последовательность событий. Их часто используют вместе, но можно применять независимо: CQRS с обычной транзакционной write-моделью или Event Sourcing с простым интерфейсом запросов.

Выбирайте Event Sourcing только когда история решений, временные запросы или восстановление состояния оправдывают сложность версионирования событий и миграций.

Ошибки внедрения

Недостаточно создать CommandDTO и QueryDTO поверх одной анемичной модели. Другой перекос — сразу разделить приложение на сервисы и базы, хотя задача решается двумя модулями в одном процессе. Избегайте общей универсальной модели чтения, которое снова начинает обслуживать все запросы.

Не помещайте бизнес-правила в обработчики проекций. Если проекция решает, допустимо ли изменение, она превратилась в скрытую write-модель.

Чек-лист CQRS-дизайна

Перед внедрением зафиксируйте, какую конкретную сложность снимает разделение и как система работает при задержке или повторе событий.

• Команды названы как бизнес-намерения?
• Инварианты остаются в агрегатах?
• Каждая проекция отвечает на конкретный вопрос?
• Определено допустимое отставание модели чтения?
• Обработчики проекций идемпотентны?
• Есть стратегия порядка и поздних событий?
• Понятно, как перестроить или мигрировать проекцию?
• Интерфейс корректно показывает асинхронную обработку?