Где я должен поместить httpRequests в архитектуру CQRS, используя Nest Js? - PullRequest
Новая
       57

Где я должен поместить httpRequests в архитектуру CQRS, используя Nest Js?

1 голос
/ 27 февраля 2020

, так что я новичок в CQRS и DDD и работаю над микросервисной архитектурой с использованием Nest js, у меня возникла эта проблема, хорошо я работа с микросервисом order , в котором я получаю объект заказа от клиента через контроллер и передаю его команде , чтобы обработать его, но сначала мне нужно проверить, что данные поставляется с объектом заказа, верно или нет, поэтому мне нужно проверить его в другие микросервисы , потому что мы не используем общий уровень данных, каждый микросервис имеет свой собственный уровень данных, например (объект имеет идентификатор клиента и Name, мне нужно проверить, действительно ли клиент существует в базе данных аутентификации микросервиса, используя httpRequests ...), так в какой слой я должен поместить мой httpRequest , находится ли он в OrderCommandHandler или я должен выполнить проверку в Уровень контроллера, создающий checkService? я хочу знать лучшие практики.

1 Ответ

1 голос
/ 27 февраля 2020

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

Лучшее решение, которое чуть лучше соответствует DDD, - это рассмотреть, какой именно процесс у вас есть, и увидеть обязанности, которые существуют. Как правило, когда вы делаете это, вы получаете границы B C (которые переходят на поверхность API микросервиса), которые более единообразны и в целом способны полностью выполнить действие.

Три варианта, которые я вижу из самого Вот небольшая информация:

  1. Разделите обработку на две части:

    1. Одна часть получает команду "OrderRequestes" и проверяет ее в соответствии с вашей компанией требования и затем запускает событие «OrderValidated»
    2. Другая часть вашей системы получает событие «OrderValidates» и обрабатывает его с неявным предположением, что данные там уже проверены, чтобы быть в порядке

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

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

...