🛠
CQRS: что это и зачем оно вамМы часто упоминаем CQRS в контексте архитектуры. Пора разобраться, что за ним стоит и когда его стоит применять.
Что такое CQRSCQRS расшифровывается как Command Query Responsibility Segregation. Суть простая: операции чтения и записи разделяются на два независимых потока.
Query — читает данные, ничего не меняет.
Command — меняет состояние, ничего не возвращает (кроме подтверждения).
В классическом подходе один репозиторий или сервис отвечает и за чтение, и за запись. Это удобно, пока система небольшая. Когда нагрузка растёт или модели чтения и записи начинают расходиться, появляются проблемы.
Какую боль решает CQRSПредставьте интернет-магазин. Команда на оформление заказа
PlaceOrderCommand обновляет остатки, создаёт запись заказа и запускает цепочку событий. А запрос на страницу каталога
GetProductsQuery просто возвращает список товаров с ценами.
Если один и тот же объект обслуживает оба сценария, вы получаете:
• модель данных, которая пытается угодить всем сразу
• сложные запросы с JOIN там, где нужна простая выборка
• трудности с масштабированием — читать нужно в 10 раз чаще, чем писать
CQRS позволяет разделить эти ответственности явно.
Как это выглядит на практикеДопустим, у нас есть приложение на C# с заказами. Для удобства используем
MediatR — библиотеку, которая берёт на себя маршрутизацию команд и запросов.
Сначала определяем интерфейсы:
public interface ICommand : IRequest { }
public interface IQuery<TResult> : IRequest<TResult> { }Команда на создание заказа:
public record PlaceOrderCommand(string UserId, string ProductId, int Quantity) : ICommand;
public class PlaceOrderCommandHandler : IRequestHandler<PlaceOrderCommand>
{
private readonly IOrderRepository _repo;
public PlaceOrderCommandHandler(IOrderRepository repo) => _repo = repo;
public async Task Handle(PlaceOrderCommand command, CancellationToken ct)
{
var order = Order.Create(command.UserId, command.ProductId, command.Quantity);
await _repo.SaveAsync(order, ct);
}
}
Запрос на получение заказов пользователя:
public record GetUserOrdersQuery(string UserId) : IQuery<IReadOnlyList<OrderDto>>;
public class GetUserOrdersQueryHandler : IRequestHandler<GetUserOrdersQuery, IReadOnlyList<OrderDto>>
{
private readonly IOrderReadRepository _readRepo;
public GetUserOrdersQueryHandler(IOrderReadRepository readRepo) => _readRepo = readRepo;
public async Task<IReadOnlyList<OrderDto>> Handle(GetUserOrdersQuery query, CancellationToken ct)
=> await _readRepo.GetByUserIdAsync(query.UserId, ct);
}
Вызов из контроллера выглядит одинаково для команд и запросов:
// Команда
await _mediator.Send(new PlaceOrderCommand(userId, productId, quantity));
// Запрос
var orders = await _mediator.Send(new GetUserOrdersQuery(userId));
Обратите внимание:
PlaceOrderCommandHandler работает с доменной моделью
Order, а
GetUserOrdersQueryHandler возвращает
OrderDto — упрощённую структуру специально для отображения. Это ключевой момент.
IOrderRepository и
IOrderReadRepository — два разных интерфейса. Первый смотрит в основную базу и знает о доменных правилах. Второй может работать с read-replica или отдельной проекцией данных.
Для чтения можно подключить read-replica или отдельную схему, оптимизированную под конкретные запросы. Запись при этом идёт в основное хранилище, а синхронизация происходит через события.
Когда применятьCQRS оправдан, если:
• нагрузка на чтение и запись сильно различается
• модели чтения и записи расходятся, например, вам нужны агрегированные данные на фронте, но нормализованное хранилище на бэке
• вы строите систему с событийной архитектурой или Event Sourcing
CQRS не нужен, если:
• у вас простой CRUD без сложной логики
• команда небольшая и накладные расходы на поддержку двух моделей не оправданы
Если вы чувствуете, что один репозиторий тащит на себе слишком много, это сигнал задуматься о разделении.
📍 Навигация:
Вакансии • Задачи •
Собесы🐸
Библиотека шарписта#il_люминатор
