Валидаторы бизнес-правил и обработчик команд в CQRS

Я новичок в CQRS, и я свяжусь с целью проверки правильности бизнес-правил внутри стороны записи (домена). Я знаю, что проверка на стороне клиента должна выполняться с точки зрения допустимой даты (обязательное поле, длина строки, действительный адрес электронной почты и т.д.), А проверка бизнес-правил/бизнес-домена должна выполняться в домене. На самом деле, те же правила проверки на стороне клиента также должны применяться к команде в домене, так как мы не доверяем пользователям.

Итак, у нас есть допустимая команда (AddEmailToCustomer), и команда command вызывается в команде. Вот мой подход к проверке.

Создайте экземпляры двух проверок команд в обработчике команд.
Сначала проверяются данные команды так же, как проверка на стороне клиента (обязательное поле, действительный адрес электронной почты и т.д.).
Второй валидатор проверяет данные на основе логики во втором валидаторе. Что-то вроде "этот клиент активен" или что-то еще. Я знаю, что меняющаяся электронная почта не подходит сюда, но это не важно. Важным является то, что здесь есть валидация бизнеса.
Мы смотрим на ValidationResult, возвращаемый Validator.Validate(ICommand cmd), и мы обнаруживаем, что есть ошибки.
Мы не хотим, чтобы клиент из репозитория вызывал метод UpdateEmail в AR. Итак, что мы будем делать в этот момент?

Выбрасывать и исключать в обработчике команд и добавлять туда эти ошибки? Отправить команду в очередь ошибок или где-то еще? Я отвечаю с чем-то вроде Bus.Reply и возвращает код ошибки? Если да, что мне делать с сообщениями об ошибках? Как сообщить эти ошибки пользователю? Я знаю, что могу отправить их позже, но в веб-сценарии я могу отправить идентификатор запроса в команде (или использовать идентификатор сообщения) и опросить ответ с идентификатором запроса и отобразить сообщения об ошибках пользователю.

Ваше руководство ценится.

Спасибо

Ответ 1

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

По крайней мере, вы можете столкнуться с нарушением concurrency, которое не может быть обнаружено до тех пор, пока не будет затронут общий корень.

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

Валидация не может не за пределами сущности - это проверка вашей бизнес-логики. Эта проверка зависит от контекста, в котором она выполняется (см. Udi Dahan Clarified CQRS).

Бизнес-логика должна не находиться в отдельной службе проверки. Он должен быть в вашем домене.

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

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

Наконец, вам нужно будет сбросить команды, отклоненные из обработчика. Я делаю это с исключениями насколько возможно.