CQRS у NestJS: практичний посібник про справжні компроміси

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

Підхід окупає свою ціну, коли правила запису складні, читання потребує істотно іншої форми чи масштабу, кільком споживачам потрібні похідні подання або єдина модель змушує обидві сторони до шкідливих компромісів. Він може прояснити відповідальність у зрілій предметній області й дати змогу оптимізувати шляхи читання без послаблення цілісності запису. Водночас він додає поняття, проміжні рівні, способи відмови, випробування, телеметрію та експлуатаційну роботу.

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

Які проблеми справді розв’язує CQRS

Спільна модель CRUD часто перевантажується у впізнаваний спосіб. Запис під час оформлення замовлення має перевірити запаси, кредит, знижки та правила протидії шахрайству, а сторінці клієнта потрібен швидкий денормалізований підсумок замовлення. Робоча панель поєднує багато агрегатів і часто змінюється, тоді як транзакційна модель має залишатися консервативною. Аудиторам потрібна стабільна історія, пошуку — окремий індекс, мобільним клієнтам — компактні подання. Спроба обслужити всі потреби одним графом об’єктів породжує надмірні сховища, випадкові записи, дорогі з’єднання таблиць і важкі для розуміння дозволи.

CQRS розділяє цей тиск. Сторона запису приймає намір, завантажує достовірний стан, застосовує незмінні правила, фіксує результат і записує потрібну подальшу роботу. Сторона читання відкриває спеціалізовані подання, які можна денормалізувати, кешувати, індексувати або зберігати окремо. Такий поділ здатний поліпшити зрозумілість і швидкодію, але створює проміжок неузгодженості: успішний запис може з’явитися не в кожній проєкції одразу.

Визначте цей проміжок мовою продукту. Чи має екран підтвердження після оформлення замовлення відразу бачити новий запис? Чи може аналітична панель відставати на хвилину? Чи дозволено службі підтримки діяти за проєкцією десятихвилинної давності? Установіть вимоги до свіжості, часу відновлення проєкції, джерела істини та поведінки для користувача під час відставання. До перепроєктування виміряйте вартість запитів, конкуренцію за запис, зв’язування випусків і характер інцидентів. CQRS має сенс, коли новий бюджет відмов кращий за старий, а не просто коли класи читання й запису отримали різні назви.

Команди й запити потребують різної семантики

Команда — це вказівка зі змістом для бізнесу: ApproveInvoice, ReserveStock, ChangeCustomerLimit. Називайте її за наміром, а не способом передавання. Обробник автентифікує контекст, авторизує дію, перевіряє поточний стан, виконує одну транзакцію свого власника й повертає мінімальний потрібний викликачеві результат. Команди, які можуть повторитися на ненадійній межі, потребують стратегії ідемпотентності. Уникайте універсальної команди з довільним набором змін: вона приховує незмінні правила й робить авторизацію залежною від змінного набору полів.

Запит просить відомості й не повинен спричиняти побічних дій у бізнесі. Проєктуйте його навколо рішення споживача: GetCheckoutSummary, SearchOpenDisputes, ListAccountsRequiringReview. Обробники запитів можуть використовувати оптимізований SQL, подання, репліки, кеші чи пошукові індекси, не відтворюючи агрегат запису. Проте їм однаково потрібні авторизація, поділ на сторінки, обмежені фільтри, правила свіжості та захист від надто дорогих форм відповіді.

CommandBus і QueryBus у NestJS забезпечують послідовне передавання та реєстрацію обробників. Вони не замінюють звичайні виклики методів автоматично. Шини всередині процесу додають проміжний рівень, тому використовуйте їх там, де іменовані запити, конвеєри, вимірювання або архітектурні межі виправдовують цю ціну. Обробник має бути досить стислим, щоб показувати керування сценарієм, і досить змістовним, щоб відповідати за нього. Якщо кожен обробник лише передає виклик однойменній службі, команда, можливо, додала церемонію без справжнього поділу.

Якщо бракує виконавців, команда розробки на NestJS має реалізувати один обмежений зріз із доказами прийнятності й передаванням знань, а не рознести шини всією кодовою базою за один раз.

Події створюють зобов’язання щодо надійності

Предметна подія повідомляє про факт, який модель-власник уже прийняла: OrderPlaced, TransferSettled, SubscriptionSuspended. Вона сформульована в минулому часі й незмінна. Подія може оновити проєкцію, спричинити сповіщення, розпочати робочий процес або повідомити інший обмежений контекст. Такий поділ корисний лише тоді, коли правила доставлення визначені явно.

EventBus усередині процесу не стає автоматично надійним брокером повідомлень. Якщо транзакція бази даних завершиться, а процес зупиниться до публікації, подальша робота може зникнути. Якщо брокер доставить повідомлення повторно, споживачі можуть виконатися двічі. Коли зміна стану й повідомлення мають пережити відмову разом, використовуйте транзакційну вихідну скриньку або інший перевірений атомарний спосіб передавання. Надайте повідомленням сталі ідентифікатори й версійовані схеми; зробіть споживачів ідемпотентними; визначте область упорядкування, межі повторів, затримку між ними, опрацювання невручених повідомлень, строк зберігання, повторне відтворення та відповідальність.

Не приховуйте обов’язкове синхронне правило за асинхронною подією. Якщо замовлення не можна підтвердити без резервування товару, визначте місце цього правила й те, що побачить клієнт у період невизначеності. Саги можуть координувати тривалі реакції, але не є розподіленими транзакціями. Для кожного кроку потрібні граничний час, ідемпотентність, спостережуваний стан і шлях компенсації або звіряння.

Під час експлуатації вимірюйте затримку публікації, відставання споживачів, вік найстарішого повідомлення, повтори, повідомлення, що постійно спричиняють збій, свіжість проєкцій і розбіжності в бізнес-даних. Ідентифікатори зв’язування та причинності мають поєднувати початкову команду з її подіями й наслідками. Без цих сигналів уявна витонченість обробників перетворюється на інцидент, розсіяний невидимими чергами.

CQRS не вимагає зберігати стан як послідовність подій

CQRS і подієве зберігання стану розв’язують різні проблеми. CQRS розділяє моделі запису й читання. За подієвого зберігання прийняті зміни агрегату записуються як незмінна послідовність подій, а поточний стан відтворюється їх повторним застосуванням. Система може використовувати команди, звичайну реляційну модель запису, вихідну скриньку й одну або кілька проєкцій, не перетворюючи події на головне джерело істини.

Такий простіший варіант часто є відповідальним першим кроком. Транзакція бази зберігає незмінні правила запису; вихідна скринька надійно фіксує публікацію; виконавці проєкцій будують моделі читання; звіряння виявляє прогалини. Система все одно потребує розвитку схем, ідемпотентності, процедур відновлення, допустимого відставання та явних правил джерела істини, проте не прив’язує всю предметну область до потоків подій.

Подієве зберігання стає привабливим, коли історія в часі має центральне значення, минулий стан потрібно відтворювати, рішення бізнесу потребують тривалого пояснювального запису або альтернативні проєкції з повної історії дають істотну цінність. Ціна висока: версії подій, перетворення старих подій до сучасної форми, стратегія знімків, побічні дії повторного відтворення, вимоги до приватності й видалення, налагодження в часі та відновлення великих потоків. Таблиця аудиту не обов’язково є подієвим сховищем, а подієве сховище не стає автоматично розв’язанням для аудиту.

Ухвалюйте ці два рішення окремо. Спочатку з’ясуйте, чи усуває виміряну проблему поділ моделей команд і запитів. Потім перевірте, чи є журнал подій найкращою достовірною моделлю зберігання саме для цього агрегату. Звичка поєднувати обидва підходи множить складність раніше, ніж доведено користь будь-якого з них.

Коли CQRS стає невигідним компромісом

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

Тривожні ознаки — окремі класи команд і запитів для кожної дрібної точки API, обробники, що лише перейменовують методи служб, події як синхронні зворотні виклики, проєкції без вимог до свіжості та брокер повідомлень без відповідального. Архітектура також підозріла, якщо локальне налагодження потребує простежувати п’ять абстракцій, входження нових розробників сповільнюється, випуски залишаються тісно пов’язаними або команда не вміє безпечно відновити модель читання.

До поділу моделей спробуйте дешевший засіб, що відповідає проблемі: поліпшіть індекси й SQL, створіть подання бази, додайте сховище читання, ізолюйте предметний модуль, кешуйте один дорогий результат, перенесіть повільну дію в надійне завдання або виправте нечіткий контракт API. Ці зміни можуть дати більшість користі без нової моделі узгодженості.

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

Перевіряйте узгодженість, дублювання та відновлення

Перевіряйте обробники команд на незмінних правилах бізнесу: дозволених переходах стану, авторизації, межах транзакцій, конфліктах одночасності, ідемпотентності та зовнішніх відмовах. Модульне випробування може пояснити правило, а інтеграційні мають довести обмеження бази даних, блокування чи оптимістичне керування одночасністю, атомарність вихідної скриньки та поведінку адаптерів. Не підміняйте імітаціями механізми з найбільшим ризиком.

Перевіряйте запити на авторизацію, фільтри, поділ на сторінки, сортування, плани виконання, межі розміру даних, правила кешу й застарілі дані. Контрактні випробування мають захищати схеми, видимі клієнтам. Проєкції потрібно перевіряти на дубльованих, відсутніх, затриманих, переставлених подіях і повідомленнях, що спричиняють збій; відновлення має давати те саме подання з тієї самої прийнятої історії. Перевірте, як нова версія проєкції працює поряд зі старою, наздоганяє її, порівнюється, приймає запити й відкочується.

Наскрізні сценарії мають перетинати проміжок неузгодженості. Виконайте команду, підтвердьте достовірний результат, простежте поступ проєкції та перевірте досвід користувача до й після узгодження. Штучно спричиняйте відмови брокера, бази даних і споживача. Перевірте звіряння за перерваної публікації чи оброблення. Для агрегатів із подієвим зберіганням додатково перевірте розвиток подій, знімки, ізоляцію повторного відтворення та засоби, що не дозволяють йому повторити зовнішні побічні дії.

Упевненість у робочій системі залежить від діагностики. Кожна команда повинна мати ідентичність і контекст зв’язування; обробники — повідомляти тривалість і результат без витоку чутливих даних; проєкції — показувати відставання й контрольні точки; звіряння — виявляти розбіжності. У кожного сповіщення мають бути відповідальний та експлуатаційна інструкція. Успішні відповіді HTTP нічого не означають, якщо прийняті команди непомітно накопичуються у вихідній скриньці.

Переносьте по одному цінному наскрізному зрізу

Не починайте перенесення на CQRS із перебудови всіх точок API. Оберіть один болісний обмежений шлях із вимірюваним результатом, наприклад повільну робочу панель, пов’язану зі стабільним процесом замовлень. Зафіксуйте вихідні показники затримки, частоти помилок, навантаження на базу даних, часу від початку зміни до випуску та зусиль на інциденти. Визначте правила узгодженості й відкату до написання першого обробника.

Спочатку зробіть наявний шлях запису явним і захистіть його незмінні правила. Додайте іменовану команду на прикладній межі, не змінюючи зберігання. Потім опублікуйте надійний запис зміни, побудуйте одну проєкцію поряд із поточним шляхом читання й заповніть її історичними даними з надійного джерела. Постійно порівнюйте старі й нові результати, включно з дозволами та граничними випадками. Спрямуйте невелику групу користувачів на новий запит, стежте за свіжістю та використанням ресурсів, а тоді розширюйте охоплення.

Поки старі й нові споживачі працюють разом, застосовуйте версійовані події та сумісні додаткові зміни схем. Подвійний запис із прикладного коду крихкий; віддавайте перевагу атомарній вихідній скриньці, захопленню змін даних із добре зрозумілими правилами або іншому керованому способу передавання. Відкат проєкції може означати повернення читання до старої моделі, тоді як відкат запису іноді потребує сумісності, а не скасування вже прийнятих дій бізнесу.

Після стабілізації зрізу перевірте, чи перевищила виміряна користь вартість створення й експлуатації. Задокументуйте підходи, які варто повторювати, винятки та модель відповідальності. Переносьте наступний зріз лише за наявності доказів. Такий поступовий підхід пов’язує архітектуру із цінністю продукту й залишає команді кілька безпечних точок зупинки.

Коли корисна незалежна перевірка CQRS

Незалежна перевірка корисна, коли CQRS поширився без вимірюваної користі, проєкції розходяться з достовірними даними, інциденти губляться між базою та брокером, контракти подій блокують випуски або команда розглядає подієве зберігання переважно тому, що вже використовує події. Вона також допомагає перед виділенням цінного обмеженого контексту чи перенесенням критичного робочого процесу.

Якісне оцінювання простежує справжні команди й запити, відображає незмінні правила та джерела істини, вимірює поведінку запитів і проєкцій, досліджує межі транзакцій та публікації, відтворює дублікати й відмови, перевіряє авторизацію між моделями та порівнює простіші варіанти. Результат має впорядкувати ризики, визначити найменший виправданий обсяг, установити докази узгодженості й відновлення, призначити експлуатаційну відповідальність і залишити поетапний план упровадження або спрощення.

Зовнішні знання мають зменшувати залежність від зовнішніх знань. Вимагайте записів рішень, спільної роботи, нотаток перевірки, схем, що відповідають коду, випробуваних експлуатаційних інструкцій та вправи з передавання, у якій команда-власник відновлює проєкцію, діагностує відставання й виконує відкат. Результат цінний, коли команда може пояснювати й експлуатувати компроміси без присутності перевіряльника.

• Проблема й межа: до розділення моделей назвіть обмежений контекст, болісний шлях, вихідні й цільові показники, джерело істини, відповідального та простіші альтернативи.
• Семантика команд і запитів: визначте намір, незмінні правила, авторизацію, ідемпотентність, межі транзакції, форму читання, поділ на сторінки, свіжість і обмеження вартості.
• Надійність подій: оберіть надійний спосіб передавання, версіонуйте схеми, зробіть споживачів ідемпотентними й призначте відповідальних за порядок, повтори, невручені повідомлення, повторне відтворення, звіряння та відставання.
• Рішення про зберігання: оцінюйте CQRS і подієве зберігання окремо; задокументуйте достовірний стан, потребу в історії, обов’язки щодо приватності, стратегію відновлення та розвиток подій.
• Бюджет складності: доведіть, чому цільовий SQL, подання, кеш, сховище читання, надійне завдання або чіткіший модуль не можуть дешевше усунути обмеження.
• Докази й випуск: на одному зрізі, наближеному до робочої системи, перевірте дублікати, затримку, зміну порядку, відмову, відновлення, авторизацію, перенесення, відкат, спостережуваність та інструкції команди.