Каковы недостатки добавления специализированного порта при использовании шестиугольной архитектуры?

Question

У вас есть набор микросервисов A, B, C, которые по разным причинам взаимодействуют с микросервисом D, и однажды вы обнаруживаете, что иногда одно из полей ввода одного из REST Apis of D потенциально необходимо очистить или преобразовать,соединяя это с некоторой другой информацией. В основном у вас есть два варианта:

1. Реализация службы E и запись логики в A, B, C, которая взаимодействует с E перед вызовом D
2. Реализация специализированного порта в D и обработкаотображение, очистка и преобразование там

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

Answer 1

С моей точки зрения, работа по преобразованию входных параметров rest api of D должна выполняться адаптером драйвера D, т.е. контроллером rest, который принимает запрос rest и вызывает службу приложенияD.

Answer 2

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

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

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

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

Удачи!

Answer 3

Извините, ответов нет, просто вопросы о характере этих услуг:

• Кому принадлежит эта логика преобразования модели? Это относится к бизнес-сфере D? Или предполагается, что он решает тонкости ввода, предоставленного одним из клиентов?

• Говоря о преобразовании модели, вы используете слово «чистый». Означает ли это очистку избыточной информации, или вам действительно нужно удалить некоторые конфиденциальные детали, которых вообще не должно быть?

• Кроме того, каковы причины этого изменения? Если логика должна будет измениться, будет ли она меняться параллельно с D, клиентами или всеми ними?