Как реализовать CQS с изменениями в памяти?
-
16-09-2019 - |
Вопрос
Посмотрев это видео Грега Яунда на DDD
http://www.infoq.com/interviews/greg-young-ddd
Мне было интересно, как вы могли бы реализовать разделение команд и запросов (CQS) с помощью DDD, когда у вас есть изменения в памяти?
С CQS у вас есть два репозитория, один для команд, другой для запросов.А также две группы объектов: командные объекты и объекты запросов.Командные объекты имеют только методы и никаких свойств, которые могли бы отображать форму объектов и не должны использоваться для отображения данных на экране.Объекты запроса, с другой стороны, используются для отображения данных на экране.
В видео команды всегда обращаются к базе данных, и поэтому вы можете использовать репозиторий запросов для извлечения обновленных данных и повторного отображения на экране.
Не могли бы вы использовать CQS с чем-то вроде и редактировать экран в ASP.NET, где изменения вносятся в память, и экран необходимо несколько раз обновлять изменениями, прежде чем изменения будут сохранены в базе данных?
Например
- Я извлекаю объект запроса из репозитория запросов и отображаю его на экране
- Я нажимаю изменить
- Я повторно извлекаю объект запроса из репозитория объектов запроса и отображаю его в форме в режиме редактирования
- Я изменяю значение в форме, которая автоматически отправляет обратно и извлекает объект command и выдает соответствующую команду
- ЧТО ДЕЛАТЬ:Теперь мне нужно отобразить обновленный объект, поскольку команда внесла изменения в вычисляемые поля.Поскольку объект command не был сохранен в базе данных, я не могу использовать репозиторий запросов.И с CQS я не собираюсь выставлять форму объекта command для отображения на экране.Как бы вы вернули объект запроса с обновленными изменениями для отображения на экране?
Пара возможных решений, о которых я могу подумать, - это иметь хранилище сеансов или способ получения объекта запроса из объекта command.Или CQS не применим к этому типу сценариев?
Мне кажется, что в видео изменения сразу сохраняются в базе данных, и я не нашел примера DDD с CQS, который бы решал проблему пакетной передачи изменений в объект домена и обновления представления измененного объекта домена перед окончательной выдачей команды для сохранения объекта домена.
Решение
Если вы действительно хотите использовать CQS для этого, я бы сказал, что и репозиторий запросов, и репозиторий записи имеют ссылку на одно и то же хранилище резервных копий.Обычно эта ссылка осуществляется через внешнюю базу данных, но в вашем случае это может быть список<T> или аналогичный.
Другие советы
Итак, похоже, что вам нужна здесь более детализированная команда.
НАПРИМЕР:пользователь взаимодействует с веб-страницей (скажем, оформляет заказ с помощью корзины покупок).
Несколько страниц, получающих информацию, создают команду.Команда не будет отправлена до тех пор, пока пользователь на самом деле проверяет, откуда вся информация отправляется в домен одной командой, давайте назовем это командой "Оформить заказ".
Презентационные модели весьма полезны для абстрагирования такого типа взаимодействия.
Надеюсь, это поможет.
Грег
Также и по остальным вашим вопросам ...
Это в большей степени касается возможной согласованности, в отличие от CQRS.Вам не нужно в конечном итоге согласовываться с CQRS, вы можете сделать так, чтобы обработка команды также записывалась в хранилище отчетов (или использовать одно и то же физическое хранилище для обоих, как упоминалось) согласованным образом.На самом деле я рекомендую людям использовать это в качестве своей базовой архитектуры, а позже проработать и внедрить конечную согласованность там, где это необходимо, поскольку с этим связаны определенные затраты.
В памяти вы обычно использовали бы Шаблон проектирования наблюдателя.
На самом деле, вы всегда хотите использовать этот шаблон, но большинство баз данных не предлагают эффективного способа вызова метода в вашем приложении при изменении чего-либо в базе данных.
В Единица работы шаблон дизайна из Шаблоны архитектуры корпоративного приложения очень хорошо соответствует CQS - по сути, это большая команда, которая сохраняет данные в базе данных.
JdonFramework - это java-фреймворк CQRS DDD, он предоставляет доменные события + асинхронный шаблон, более подробная информация https://jdon.dev.java.net/