Шестиугольная архитектура / порты и адаптеры: конфигурация приложения с несколькими адаптерами драйверов

Я ищу некоторые рекомендации или лучшие практики по настройке и структурированию приложения, которое соответствует гексагональной архитектуре, которая поддерживает несколько адаптеров (драйверов) одновременно.

Мой API / уровень приложения / порты представляют собой границы приложения. Сейчас я пишу адаптеры драйверов с целью, чтобы приложение поддерживало как адаптер консоли / интерфейса командной строки, так и адаптер REST в тандеме.

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

  • Единый главный компонент, который настраивает все приложение: включая все основные адаптеры. Вместе с загрузкой конфигурации приложения. В этом случае он запустит службы REST и запустит консольное приложение CLI.

  • Отдельный основной компонент для каждого типа основного адаптера. т.е. Один для приложения REST. Один для приложения CLI / Console. Меня беспокоит то, что это приведет к большому дублированию настройки приложения в пределах границ (например, служб API, репозиториев и т. Д.).

  • Следуйте описанному выше подходу, но извлеките общую конфигурацию / проводку в общий класс.

Если у кого-то есть какие-то примеры, которыми они могли бы поделиться, было бы интересно посмотреть.

Ваше здоровье,

Стив


clean-architecture configuration composition hexagonal-architecture
person Steven    schedule 21.10.2019    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Это интересный вопрос.

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

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

Тем не менее, я изучил два подхода к запуску системы:

(1) Чтобы иметь дополнительный компонент (назовите его главный компонент, корень композиции, запуск, инициализация или как хотите), который создает экземпляры управляемых адаптеров и шестиугольника, и, наконец, создает экземпляры адаптеров драйверов и запускает их. Таким образом, архитектура системы будет выглядеть как контейнер приложения на стороне драйвера и архитектура плагина на стороне привода.

(2) Для запуска каждого адаптера драйвера отдельно. Именно адаптер драйвера запускает игру, запрашивая у шестиугольника экземпляр порта драйвера, а шестиугольник запрашивает у каждого ведомого порта экземпляр ведомого адаптера.

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

Я написал теоретическую статью о гексагональной архитектуре по адресу https://softwarecampament.wordpress.com/portsadapters/ , а сейчас я работаю над статьей о том, как реализовать гексагональную архитектуру, и примером кода.

person choquero70    schedule 22.10.2019
comment
Спасибо. Это очень помогло найти лучший подход для моей ситуации. - person Steven; 30.10.2019