Вопрос

Мы пробуем CQRS.У нас есть ситуация проверки, когда CustomerService (доменная служба) должна знать, существует Клиент или нет.Клиенты уникальны по своему адресу электронной почты.В нашем клиентском репозитории (универсальном репозитории) есть только Get (id) и Add (customer).Как CustomerService должна узнать, существует ли Клиент?

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

Решение

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

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

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

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

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

Удачи вам!

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

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

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

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

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

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

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

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

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

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

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