Перейти на PRO

Что такое паттерн CQRS и в чем его основная идея

Тип вопроса: Паттерны Вероятность: 10% Категория: Python Разработчик

Ответ

CQRS (Command Query Responsibility Segregation) — это архитектурный паттерн, который предлагает разделять модели и логику для операций изменения состояния (Commands) и операций чтения данных (Queries).

Основная идея: Вместо единой модели для всех CRUD-операций создаются две отдельные, специализированные модели:

  1. Command Model (модель команд): Отвечает за изменение состояния системы (создание, обновление, удаление). Команды не должны возвращать данные.
  2. Query Model (модель запросов): Отвечает только за чтение данных. Эта модель может быть денормализована и оптимизирована для быстрых и сложных выборок.

Ключевые преимущества:

  • Масштабируемость: Позволяет независимо масштабировать сервисы чтения и записи. Например, можно иметь один мощный сервер для записи и множество легковесных реплик для чтения.
  • Оптимизация: Модель для чтения может использовать другую технологию хранения (например, Elasticsearch или Redis), идеально подходящую для конкретных запросов, в то время как модель записи использует транзакционную реляционную БД (например, PostgreSQL).
  • Гибкость и безопасность: Четкое разделение логики упрощает разработку и тестирование. Можно настроить разные права доступа для команд и запросов.

Упрощенный пример на Python:

# --- Command Side --- #
class ProductRepository:
    def save(self, product):
        # Логика сохранения в основную БД (например, PostgreSQL)
        print(f"Сохранение продукта '{product.name}' в основную базу данных.")

class ProductCommands:
    def __init__(self):
        self.repo = ProductRepository()

    def create_product(self, name, price):
        product = Product(name=name, price=price)
        self.repo.save(product)
        # Команда не возвращает результат

# --- Query Side --- #
class ProductQueries:
    def get_product_list_for_display(self):
        # Чтение из оптимизированной для чтения реплики или кэша (например, Redis)
        print("Получение списка продуктов из денормализованного хранилища.")
        return [{"name": "Laptop", "price_formatted": "$1200.00"}]

Когда применять: CQRS эффективен в сложных системах с высокой нагрузкой на чтение и высокими требованиями к производительности. Паттерн является избыточным для простых CRUD-приложений из-за вносимой им сложности.

Ответ 18+ 🔞

Давай я тебе на пальцах объясню, что за зверь такой — CQRS. Представь себе, что ты в ресторане, блядь. Там же не один и тот же человек и котлеты жарит, и меню тебе приносит, и счёт выписывает, и посуду моет, ёпта! Это ж пиздец будет, один мужик сгорит нахуй, а очередь до завтра.

Так вот, CQRS — это как раз про такое разделение труда, только для твоего кода.

Суть проще пареной репы: Есть два брата-близнеца, но один — Командир (Command), а второй — Спрашивайло (Query).

  1. Командир — это тот, кто меняет что-то в системе. Создал заказ, обновил профиль, удалил коммент. Его дело — сделать дело и не выёбываться. Он НИЧЕГО НЕ ВОЗВРАЩАЕТ. Сделал — и пошёл нахуй. Как почтальон, который письмо опустил в ящик и не ждёт, пока ты его прочтёшь и похвалишь.
  2. Спрашивайло — это полная его противоположность, хитрая жопа. Его работа — только читать и отдавать данные. Причём он может для скорости наколдовать себе любую удобную форму этих данных, хоть в три горба, лишь бы быстро. Он не имеет права ничего менять, только смотреть и докладывать.

Зачем этот цирк? А затем, ёпта, что когда у тебя один мужик на всё про всё, он начинает тупить. База данных одна, и она пытается и транзакции записать, и десять сложных отчетов для начальства выдать. В итоге всё встаёт колом, терпения ноль ебать.

А с CQRS ты можешь:

  • Масштабировать их по отдельности. Если у тебя народ только читает ленту (Спрашивайло заебётся), ты ставишь ему десять быстрых серверов-помощников. А Командир пусть себе на одном мощном серваке скрипит, записывая данные. И они друг другу не мешают.
  • Оптимизировать под задачу. Командир пусть пишет в надёжный PostgreSQL, как в сейф. А Спрашивайло может данные для отчётов тырить в супербыстрый Redis или Elasticsearch, где всё уже приготовлено, как в столовой, только бери и жри.
  • Не запутаться. Логика чётко разделена. Один код отвечает за изменение, другой — за показ. Тестировать и понимать в разы проще, волнение ебать — на нуле.

Смотри, как это выглядит в коде (не трогаю его, как договаривались):

# --- Сторона Командира (пишем в сейф) --- #
class ProductRepository:
    def save(self, product):
        # Логика сохранения в основную БД (например, PostgreSQL)
        print(f"Сохранение продукта '{product.name}' в основную базу данных.")

class ProductCommands:
    def __init__(self):
        self.repo = ProductRepository()

    def create_product(self, name, price):
        product = Product(name=name, price=price)
        self.repo.save(product)
        # Команда не возвращает результат! Сделал и свободен.

# --- Сторона Спрашивайло (читаем из быстрого буфета) --- #
class ProductQueries:
    def get_product_list_for_display(self):
        # Чтение из оптимизированной для чтения реплики или кэша (например, Redis)
        print("Получение списка продуктов из денормализованного хранилища.")
        return [{"name": "Laptop", "price_formatted": "$1200.00"}] # Данные уже красивые, готовые к показу

Когда это всё охуенно нужно? Только в сложных, нагруженных системах, где чтение и запись — это два разных мира. Для своего блога-визитки или админки для учета трёх товаров — это овердохуища сложности, чисто выёбка. Там CRUD'а обычного за глаза. А вот когда у тебя миллион пользователей онлайн, один пишет пост, а десять тысяч его читают — вот тут CQRS и показывает свою мощь, блядь.

© ХакСобесов, 2026
support@hacksobesov.com