Доменные запросы в CQRS
Мы испытываем CQRS. У нас есть ситуация с проверкой, где CustomerService (доменный сервис) должен знать, существует ли Клиент. Клиенты уникальны своим адресом электронной почты. Наш Потребительский репозиторий (универсальный репозиторий) только имеет, Добираются (идентификатор) и Добавляют (клиент). Как CustomerService должен узнать, существует ли Клиент?
3 ответа
Посмотрите на эту запись в блоге: Set based validation in the CQRS Architecture.
В нем рассматривается именно эта проблема. Это сложная проблема, которую необходимо решить в CQRS. Bjarte предлагает запросить базу данных отчётов для существующих адресов электронной почты клиентов и выпустить команду Compensating Command (например, CustomerEmailAddressIsNotUniqueCompensatingCommand) обратно в Модель домена, если адрес электронной почты был найден. Затем вы можете запустить соответствующие события, которые могут включать UndoCustomerCreationEvent.
Ознакомьтесь с комментариями к вышеуказанному посту в блоге для поиска альтернативных идей.
Адам Д. в комментарии предполагает, что валидация является проблемой домена. В результате, вы можете хранить ReservedEmailAddresses в сервисе, который облегчает создание клиента и гидратируется событиями в вашем магазине событий.
Я не уверен, что существует простое решение этой проблемы, которое кажется абсолютно чистым. Дайте мне знать, что вы придумали!
Удачи!
Эта проблема не должна быть такой сложной:
- Перед отправкой команды UpdateCustomer проверьте хранилище отчетов на уникальность клиента.
- Добавьте в свою БД ограничение на уникальность адреса электронной почты. При выполнении команды обработайте исключение и отправьте уведомление пользователю, используя канал ответа. (следовательно, никогда не запускаются события CustomerUpdated в хранилище отчетов.
Используйте базу данных там, где она нужна, и не зацикливайтесь на ограничениях ORM.
Это сообщение Udi Dahan http://www.udidahan.com/2009/12/09/clarified-cqrs/ содержит следующий параграф:
"Также нам не нужно обращаться к хранилищу запросов для обработки команд - любое состояние, которое необходимо, должно управляться автономным компонентом - это часть смысла автономности."
Я полагаю, Udi предложил просто добавить уникальное ограничение к базе данных.
Но если вам не хочется этого делать, основываясь на вышеприведенном утверждении, я бы предложил просто добавить метод "ByEmail" в хранилище и покончить с этим - но опять же, Udi, вероятно, предложит лучшее предложение...