Как обрабатывать ошибки после проверки в команде (DDD + CQRS)

Например, когда вы отправляете форму регистрации, вы должны подтвердить Domain Model( WriteModelв CQRS), что она находится в действительном состоянии (например, синтаксис адреса электронной почты, возраст и т. Д.).

Затем вы создаете Commandи отправляете его Command Bus.

Я понимаю, что Команды не должны ничего возвращать.

Итак, как вы справляетесь с ошибкой Command Bus? (Например, пользователь зарегистрировался за 1 секунду до того же username/email).

Откуда вы знаете, что команда завершилась неудачно, и как вы узнали об ошибке?

Я понимаю, что Команды не должны ничего возвращать.

Это одна точка зрения, но она не совсем в камне. Рассмотрим записи (PUT, POST, DELETE) в HTTP - все эти сообщения являются командами в том смысле, что они являются сообщениями с запросом на изменение состояния ресурса, и все же они все возвращают ответы.

Итак, как вы справляетесь с ошибкой за пределами командной шины? (Например, пользователь зарегистрировался за 1 секунду до того же имени / адреса электронной почты).

Откуда вы знаете, что команда завершилась неудачно, и как вы узнали об ошибке?

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

Если вы используете часть промежуточного программного обеспечения, например, шину, которая не позволяет вам напрямую взаимодействовать с целью, то я бы посоветовал вам обратиться к шаблонам асинхронного обмена сообщениями - как заставить обработчик команд отправлять сообщение обратно вызывающий?

Одна идея состоит в том, чтобы подписаться на результат команды; это заимствовано из некоторых идей в паттернах корпоративной интеграции Hohpe. Основная идея заключается в том, что, поскольку клиент знаком с отправленным командным сообщением, он имеет все возможности для подписки на любые новые сообщения, опубликованные как следствие командного сообщения. Обработчик команд, после сохранения данных в книге записей, публикует события, объявляющие об успешном изменении, и клиент подписывается на эти события - распознавая правильные события, учитывая совпадение различных идентификаторов в сообщении (идентификатор причины, идентификатор корреляции и т. д.).

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

Очень похожая альтернатива - зарезервировать место в командном сообщении для обработчика команды, чтобы написать подтверждение - поскольку клиент уже имеет рассматриваемое командное сообщение, схема уже завершена. Подумайте « обещание » или « выполнимое будущее». Сообщение сообщает обработчику команды, где написать подтверждение; это сигнализирует клиенту (защелка обратного отсчета), что подтверждение доступно.

И, конечно, у вас есть дополнительная опция удаления промежуточного программного обеспечения, которое, кажется, мешает просто делать правильные вещи.

Например, пользователь зарегистрировался за 1 секунду до того же имени пользователя / адреса электронной почты

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

Например, когда вы отправляете форму регистрации, вы должны проверить в доменной модели (WriteModel в CQRS), что она находится в действительном состоянии (например, синтаксис адреса электронной почты, возраст и т. Д.)

Существует много видов проверки. Проверка при проверке синтаксиса адреса электронной почты и формата возраста - это тип проверки, который может выполнить команда. Это на самом деле не проблема домена. Может показаться, что это так, потому что некоторые эксперты в области сказали бы вам эти спецификации, но вы должны выполнить такую ​​проверку при создании команды. Фактически, общая идея состоит в том, чтобы выполнить проверку как можно скорее, потому что после того, как команда создана и отправлена ​​в BUS, становится сложнее выполнять действия.

Итак, как вы справляетесь с ошибкой за пределами командной шины? (Например, пользователь зарегистрировался за 1 секунду до того же имени / адреса электронной почты).

Этот вид валидации много обсуждается в сообществе CQRS с самого начала CQRS. Где это сделать? Это очень обсуждается. Я лично использую следующий подход: перед тем, как команда отправляется в BUS, я помечаю имя пользователя / электронную почту как принятые централизованным способом (то есть ограничение уникального индекса для имени пользователя / электронной почты). После этого я отправляю команду. Недостатком является то, что в случае сбоя команды в течение короткого периода времени это имя пользователя берется и не используется; это приемлемо для моего бизнеса, вероятно для вашего бизнеса.

Откуда вы знаете, что команда завершилась неудачно, и как вы узнали об ошибке?

Если асинхронная команда отклонена Агрегатом из-за инварианта домена, необходимо предпринять некоторые меры, выполнив некоторую компенсационную команду, которая каким-то образом уведомляет издателя команды (то есть отправляет объяснительное электронное письмо о том, что команда не выполнена).

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

Проверка должна быть выполнена в декораторе. Тогда любая команда, которая нуждается в проверке, может быть оформлена как таковая.

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

Другая возможность - думать о валидации как о типе «запроса», который вернул бы результат валидации. Запустите запрос проверки, а затем, если он пройден, выполните команду. Это было бы альтернативой подходу декоратора.