День 1364. #ЗаметкиНаПолях CQRS. Факты и Мифы. Окончание Начало Теперь перейдём к разбору мифов. 1. Усложняет ли CQRS архитектуру? В архитектуре CQRS вы делите свою модель и API на вертикальные слои. Каждый обработчик команд/запросов представляет собой отдельный кусок, отдельную единицу кода (новый обработчик можно создавать даже через копирование/вставку). Благодаря этому вы можете настроить конкретный метод, не следуя общим соглашениям (например, использовать чистый SQL-запрос или даже другое хранилище). В традиционной многоуровневой архитектуре изменение базового универсального механизма на одном уровне может повлиять на все методы. Но мир не идеален: иногда исключений больше, чем случаев, подпадающих под общее правило. Вертикальное разделение помогает разработчику сосредоточиться на конкретной бизнес-функции, не отвлекаясь на остальную логику приложения. 2. Почему считается, что нужно иметь разные таблицы или базы данных? CQRS позволяет настроить модель запроса в соответствии с потребностями клиентов. Типичным случаем является наличие отдельной модели чтения для каждого представления. Вам не нужны все детали объекта, если вы просто отображаете краткую сводку. Такие модели чтения могут представлять собой слегка отличающиеся SQL-запросы, выбирающие другой диапазон столбцов из таблицы. Но они также могут быть материализованными представлениями или отдельными таблицами. Можно сделать это для оптимизации производительности, чтобы записи и запросы не влияли друг на друга. Если у вас такой случай, то одно из возможных решений — использовать разные таблицы или базы данных и синхронизировать их после записи. Однако это не общее правило. Нужно выбрать стратегию, которая соответствует потребностям. 3. Откуда возникла необходимость в очередях обмена сообщениями? CQRS позволяет иметь разные хранилища для разных бизнес-кейсов. Например, реляционную базу данных в модели записи и базу данных документов в модели чтения (например, Elastic Search для полнотекстового поиска) или любую другую комбинацию. Создание модели чтения в этом случае должно иметь логику преобразования. У вас могут быть отдельные сервисы, отвечающие за бизнес-логику по изменению состояния и за постройку моделей чтения. Очереди обмена сообщениями (например, RabbitMQ, Kafka) могут помочь синхронизировать их, уведомляя процессоры модели чтения о новом изменении в модели записи. Но можно начать с малого, используя таблицы и представления базы данных или очереди в памяти. 4. Что насчёт окончательной согласованности? Если вы используете очереди сообщений или несколько баз данных, данные из хранилища для записи копируются (и преобразуются) в хранилище для чтения асинхронно. В результате хранилище чтения отстает от хранилища записи и имеет место Окончательная Согласованность (Eventual Consistency). Даже материализованные представления или репликация в базе данных могут иметь окончательную согласованность. Когда изменение, внесённое в модель записи, влияет на несколько моделей чтения в одной и той же транзакции, стоит подумать о том, является ли влияние на производительность значительным. Один из возможных подходов — выгрузить обновление в фоновый асинхронный процесс. Зная, какие изменения были внесены, вы можете обрабатывать их по одному или, например, пакетами в процессе ETL. 5. Нужен ли Event Sourcing? Нет. Event Sourcing довольно часто отождествляют с CQRS. Он по определению имеет модели Write и Read. События сохраняются в журнале только для добавления. Они являются источником истины. Модели чтения создаются и обновляются на основе событий. Event Sourcing и CQRS подходят друг другу, однако это разные парадигмы. Event Sourcing — это «всего лишь» один из вариантов, который вы можете выбрать в качестве реализации хранилища. Источник: https://event-driven.io/en/cqrs_facts_and_myths_explained/