Доменные запросы в CQRS

Ответ 1

Взгляните на это сообщение в блоге: Установить проверку на основе в архитектуре CQRS.

Он решает эту проблему. Это сложный вопрос для рассмотрения в CQRS. Что Bjarte предлагает, так это запросить базу данных отчетов для существующих адресов электронной почты клиента и выдать команду компенсации (например, CustomerEmailAddressIsNotUniqueCompensatingCommand) обратно в модель домена, если был найден адрес электронной почты. Затем вы можете запустить соответствующие события, которые могут включать UndoCustomerCreationEvent.

Прочитайте комментарии к вышеуказанному сообщению в блоге для альтернативных идей.

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

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

Удачи!

Ответ 2

Эти проблемы не обязательно должны быть такими сложными:

• Перед отправкой команды UpdateCustomer проверьте хранилище отчетов для уникальности клиента.
• Добавьте ограничение для вашей БД для уникальности на адрес электронной почты. При выполнении команды обрабатывайте исключение и отправляйте уведомление пользователю с использованием канала ответа. (курсоры никогда не запускают события CustomerUpdated в хранилище отчетов.

Используйте базу данных, для чего она хороша и не зависеть от ограничений ORM.

Ответ 3

Это сообщение Udi Dahan http://www.udidahan.com/2009/12/09/clarified-cqrs/ содержит следующий абзац:

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

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

Но если вам не нравится делать это, на основе вышеприведенного утверждения, я бы предложил просто добавить метод "ByEmail" в репозиторий и сделать с ним, но тогда Udi, вероятно, получит лучшее предложение..

Ответ 4

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

Итак, в этом случае у нас может быть класс по имени CustomerEmailMustBeUniqueRule, который извлекается RuleEngine, когда команда RegisterCustomerCommand собирается выполнить RegisterCustomerCommandExecutor. Этот класс правил несет ответственность за запрос базы данных, чтобы узнать, существует ли идентификатор электронной почты и остановить выполнение, подняв недопустимый флаг...

Ответ 5

• Используйте ORM для таблицы Customer. Таким образом, он будет генерировать исключение, как только будет введен дублирующий ключ. Вы должны использовать DapperDotNet, он очень легкий и простой в использовании. Самое приятное в использовании ORM - это то, что большинство из них позволяют вам создавать или создавать классы для представления существующих таблиц в вашем db. Он полностью отсекает ту часть, где вам нужно пройти проверку против db для существующей записи.

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

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