Разница между cqrs vs cqs

Ответ 1

CQS (разделение командного запроса) и CQRS (разделение ответственности командного запроса) очень тесно связаны. Вы можете думать о CQS как о уровне класса или компонента, в то время как CQRS больше на уровне ограниченного контекста.

Я склонен думать о CQS как о микроуровне, а CQRS - о макроуровне.

CQS предписывает отдельные методы для запроса или записи в модель: запрос не изменяет состояние, а команда изменяет состояние, но не имеет возвращаемого значения. Он был разработан Бертраном Мейером как часть его новаторской работы над языком программирования Eiffel.

CQRS предписывает аналогичный подход, за исключением того, что это скорее путь через вашу систему. Запрос запроса занимает отдельный путь от команды. Запрос возвращает данные без изменения базовой системы; команда изменяет систему, но не возвращает данные.

Грег Янг составил довольно подробное описание того, что такое CQRS несколько лет назад, и расскажет, как CQRS является эволюцией CQS. Этот документ познакомил меня с CQRS несколько лет назад, и я считаю его все еще очень полезным справочным документом.

Ответ 2

Самая большая разница заключается в том, что CQRS использует отдельные хранилища данных для команд и запросов. Хранилище запросов может использовать другую технологию, такую ​​как база данных документа, или просто быть денормализованной схемой в той же базе данных, которая упрощает запрос данных.

Данные между базами данных обычно копируются асинхронно, используя что-то вроде служебной шины. Таким образом, данные в хранилище запросов в конечном итоге согласуются (в определенный момент времени он будет находиться). Приложения должны учитывать это. Хотя для записи в обоих магазинах можно использовать одну и ту же транзакцию (такую ​​же базу данных или двухфазную фиксацию), она обычно не рекомендуется по причинам масштабируемости.

Архитектура CQS читает и записывает из одного хранилища данных/таблиц.

Ответ 3

Это старый вопрос, но я собираюсь попытаться ответить на него. Я не часто отвечаю на вопросы о StackOverflow, поэтому, пожалуйста, прости меня, если я делаю что-то вне рамок сообщества в плане ссылок на вещи, написания длинных ответов и т.д.

Существует много различий между CQRS и CQS, однако CQRS использует CQS внутри своего определения! Давайте начнем с определения двух, а затем мы можем обсудить различия.

CQS определяет два типа сообщений в зависимости от их возвращаемого значения. Нет возвращаемого значения (void) указывает, что это команда. Возвращаемое значение (не пустое) указывает, что этот метод является Запросом.

Команды изменить информацию Запросы возвращают информацию

Команды меняют состояние. Запросы нет.

Теперь для CQRS, который использует то же определение, что и CQS для команд и запросов. CQRS говорит, что нам не нужен один объект с методами Command и Query. Вместо этого мы хотим два объекта, один со всеми командами и один со всеми запросами.

Идея в целом очень проста, после всего этого все становится интересным. В Интернете много разговоров о том, что я обсуждаю некоторые связанные атрибуты (извините, что слишком много печатать здесь!)

Ответ 4

• CQS - это команда и запросы. Это не заботится о модели. Вы как-то разделили сервисы, которые только читают данные, и сервисы, которые модифицируют данные.
• CQRS - это отдельные модели для записи и чтения. Конечно, использование модели записи часто читает что-то для выполнения бизнес-логики, но вы можете выполнять чтение только на модели чтения. Отдельные базы данных являются современными. Но представьте себе одну БД с отдельными моделями для чтения и записи, смоделированными в OR/M. Это очень часто достаточно хорошо.

Я обнаружил, что люди часто говорят, что они практикуют CQRS, когда у них есть CQS.

Ответ 5

Прочитайте ответ изобретателя Грега Янга

Я думаю, что, как и "Внедрение зависимостей", концепции настолько просты и принимаются как должное, что тот факт, что у них причудливые имена, кажется, заставляет людей думать, что они нечто большее, чем они есть, особенно потому, что CQRS часто цитируется наряду с Event Sourcing.

• CQS - это разделение методов, которые читают на те, которые меняют состояние; не делайте оба в одном методе. Это микро уровень.

• CQRS расширяет эту концепцию на более высокий уровень для машинно-машинных API, разделения моделей сообщений и путей обработки.

Таким образом, CQRS - это принцип, который вы применяете к коду в API или фасаде.

Я обнаружил, что CQRS, по сути, является очень сильной S в SOLID, глубоко внедряя это разделение в психику разработчиков для создания более удобного кода.

Я думаю, что веб-приложения плохо подходят для CQRS, поскольку изменение состояния посредством передачи представления означает, что команда и запрос являются двумя сторонами одного и того же запроса-ответа. Представление - это команда, а ответ - это запрос.

Например, вы отправляете заказ и получаете просмотр всех ваших заказов.

Представьте, что код веб-сайта был включен в командную и запросную части. Код обработки действия маршрута должен был бы попасть в одну из этих сторон, но он выполняет обе задачи.

Воображая более сильную сегрегацию, если код был перемещен в две разные компилируемые кодовые базы, тогда веб-сайт примет POST формы, но пользователю придется просмотреть URL-адрес другого веб-сайта, чтобы увидеть влияние действия. Это явно безумие. Одним из обходных путей было бы всегда перенаправление, хотя на самом деле это не было бы RESTful, поскольку идеальное приложение REST - это когда следующее представление содержит гипертекст для управления следующим переходом состояния и так далее.

Учитывая, что веб-сайт является REST API между человеком и машиной (или машиной и машиной), он также включает в себя REST API, хотя другие типы API для передачи HTTP-сообщений могут идеально подходить для CQRS.

Служба или фасад в пределах веб-сайта, очевидно, могут хорошо работать с CQRS, хотя обработчики действий будут находиться за этой границей.

Смотрите CQS в Википедии