Вопрос

Посмотрев это видео Грега Яунда на DDD

http://www.infoq.com/interviews/greg-young-ddd

Мне было интересно, как вы могли бы реализовать разделение команд и запросов (CQS) с помощью DDD, когда у вас есть изменения в памяти?

С CQS у вас есть два репозитория, один для команд, другой для запросов.А также две группы объектов: командные объекты и объекты запросов.Командные объекты имеют только методы и никаких свойств, которые могли бы отображать форму объектов и не должны использоваться для отображения данных на экране.Объекты запроса, с другой стороны, используются для отображения данных на экране.

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

Не могли бы вы использовать CQS с чем-то вроде и редактировать экран в ASP.NET, где изменения вносятся в память, и экран необходимо несколько раз обновлять изменениями, прежде чем изменения будут сохранены в базе данных?

Например

  1. Я извлекаю объект запроса из репозитория запросов и отображаю его на экране
  2. Я нажимаю изменить
  3. Я повторно извлекаю объект запроса из репозитория объектов запроса и отображаю его в форме в режиме редактирования
  4. Я изменяю значение в форме, которая автоматически отправляет обратно и извлекает объект command и выдает соответствующую команду
  5. ЧТО ДЕЛАТЬ:Теперь мне нужно отобразить обновленный объект, поскольку команда внесла изменения в вычисляемые поля.Поскольку объект command не был сохранен в базе данных, я не могу использовать репозиторий запросов.И с CQS я не собираюсь выставлять форму объекта command для отображения на экране.Как бы вы вернули объект запроса с обновленными изменениями для отображения на экране?

Пара возможных решений, о которых я могу подумать, - это иметь хранилище сеансов или способ получения объекта запроса из объекта command.Или CQS не применим к этому типу сценариев?

Мне кажется, что в видео изменения сразу сохраняются в базе данных, и я не нашел примера DDD с CQS, который бы решал проблему пакетной передачи изменений в объект домена и обновления представления измененного объекта домена перед окончательной выдачей команды для сохранения объекта домена.

Это было полезно?

Решение

Если вы действительно хотите использовать CQS для этого, я бы сказал, что и репозиторий запросов, и репозиторий записи имеют ссылку на одно и то же хранилище резервных копий.Обычно эта ссылка осуществляется через внешнюю базу данных, но в вашем случае это может быть список<T> или аналогичный.

Другие советы

Итак, похоже, что вам нужна здесь более детализированная команда.

НАПРИМЕР:пользователь взаимодействует с веб-страницей (скажем, оформляет заказ с помощью корзины покупок).

Несколько страниц, получающих информацию, создают команду.Команда не будет отправлена до тех пор, пока пользователь на самом деле проверяет, откуда вся информация отправляется в домен одной командой, давайте назовем это командой "Оформить заказ".

Презентационные модели весьма полезны для абстрагирования такого типа взаимодействия.

Надеюсь, это поможет.

Грег

Также и по остальным вашим вопросам ...

Это в большей степени касается возможной согласованности, в отличие от CQRS.Вам не нужно в конечном итоге согласовываться с CQRS, вы можете сделать так, чтобы обработка команды также записывалась в хранилище отчетов (или использовать одно и то же физическое хранилище для обоих, как упоминалось) согласованным образом.На самом деле я рекомендую людям использовать это в качестве своей базовой архитектуры, а позже проработать и внедрить конечную согласованность там, где это необходимо, поскольку с этим связаны определенные затраты.

В памяти вы обычно использовали бы Шаблон проектирования наблюдателя.

На самом деле, вы всегда хотите использовать этот шаблон, но большинство баз данных не предлагают эффективного способа вызова метода в вашем приложении при изменении чего-либо в базе данных.

В Единица работы шаблон дизайна из Шаблоны архитектуры корпоративного приложения очень хорошо соответствует CQS - по сути, это большая команда, которая сохраняет данные в базе данных.

JdonFramework - это java-фреймворк CQRS DDD, он предоставляет доменные события + асинхронный шаблон, более подробная информация https://jdon.dev.java.net/

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top