Патерн CQRS для складних доменів

Суть розділення

CQRS (Command Query Responsibility Segregation) пропонує використовувати різні моделі для запису і читання даних замість однієї універсальної. Команда, яка змінює стан, проходить через модель запису з повною бізнес-логікою і валідацією, а читання обслуговується окремою, часто денормалізованою моделлю, оптимізованою під конкретні екрани інтерфейсу. Детальніше про суміжний підхід можна прочитати в матеріалі «Ідемпотентність API: як уникнути дублів операцій».

Коли це виправдано

Для простого CRUD-застосунку CQRS — надлишкова складність: дві моделі, синхронізація між ними, можлива затримка реплікації даних у модель читання. Патерн розкривається в складних доменах, де логіка запису сильно відрізняється від того, що потрібно показати користувачу — наприклад, у фінансових системах, де транзакція перевіряється десятком бізнес-правил, а на екрані користувач бачить лише агрегований баланс.

Часта комбінація — CQRS разом з Event Sourcing: події стають джерелом істини для моделі запису, а модель читання перебудовується їх послідовним застосуванням. Це дає повну історію змін і можливість будувати скільки завгодно read-моделей під різні потреби, ціною помітно зрослої складності інфраструктури. Ці ідеї перегукуються з темами «Обробка помилок у розподілених системах» та «Моніторинг і алертинг: будуємо спостережуваність сервісу».