Раньше на канале выходили посты про технические штуки:
ConfigMap: Что такое и зачем?
Что такое Feign?
MAPI: что это и зачем знать аналитикам?
Что такое DTO и зачем это знать аналитику?
HAProxy: зачем это знать аналитику?
Mapping: что это такое и зачем знать аналитику?
Хочется сделать из этого отдельную рубрику про вещи, которые все скорее всего знают, они на слуху, но если спросить, в ответ услышишь: «ну блин, это же это вот, да блин, все знают, ёмоё» 🙂
Что такое CQRS?
CQRS — архитектурный паттерн. Расшифровывается как Command Query Responsibility Segregation — разделение ответственности команд и запросов.
По-простому: операции чтения (Query) и изменения данных (Command) разделяются и живут независимо друг от друга.
В классическом подходе команды и запросы идут вместе. CQRS говорит: разделите их. Пусть каждый занимается своей задачей.
Пример🏦
Допустим, есть сервис работы со счетами.
Есть сервис счетов.
Пользователи постоянно:
— смотрят баланс
— открывают историю операций
Это чтение.
Параллельно идут:
— переводы
— пополнения
— списания
Это запись.
Если использовать одну модель для всего, то при высокой нагрузке они начинают мешать друг другу:
тяжёлые операции записи тормозят чтение, а частые запросы будут перегружать систему.
CQRS решает это разделением: отдельная модель для чтения, отдельная для записи. И дальше это можно удобно масштабировать.
Важный момент: CQRS не обязательно означает две отдельные модели данных. Модель может быть одна, но пути для чтения и записи разные. Две модели — это один из вариантов реализации, который часто используют вместе с Event Sourcing.
Когда применять, а когда нет 🤔
Подойдет, если:
🆗 Нагрузка на чтение и запись сильно отличается
🆗 Сложная бизнес-логика на запись
🆗 Есть требования к производительности
🆗 Нужна независимая масштабируемость в процессах
Не лучший вариант, если у вас:
❌ Простое CRUD-приложение
❌ Маленький проект и команда
❌ нет понимания, зачем это нужно
❌ Не готовы к сложности синхронизации — если используете две модели, данные для чтения могут отставать от записи (eventual consistency)
Зачем это знать аналитику?
Потому что именно ты описываешь как данные читаются и записываются в системе. Если сервис небольшой, можно и забить. Но если архитектора нет — возможно именно ты поможешь спроектировать решение, которое потом не придётся переделывать.
Ну и на собесе спросят. Лучше ответить нормально, чем мычать 🙂
А вы сталкивались с CQRS в своих проектах?
#технические_штуки
IT АНАЛитика | Подписаться