Гексагональная архитектура (Iytvgikugl,ugx gj]nmytmrjg)

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

Появление

Гексагональная архитектура была представлена Алистером Кокберном у него в блоге^[1] в 2005 году в попытке избежать известных структурных ошибок в объектно-ориентированном проектировании программного обеспечения, таких как нежелательные зависимости между бизнес-логикой и пользовательским интерфейсом.

Термин «гексагональный» происходит от графичиского обозначения этой архитектуры, согласно которому ядро проекта изображается в виде шестиугольной ячейки. Главной целью у гексагональной архитектуры является отделение компонентов, входящими в ядро проекта от компонентов, к нему не относящимся. К ядру программы, например, не относятся контроллеры, репозитории или презентаторы. Все они в гексагональной архитектуре относятся к инфраструктурным компонентам.

Принцип работы

Гексагональная архитектура делит программное обеспечение на несколько слабосвязанных компонентов: ядро проекта, база данных, пользовательский интерфейс, тестовые сценарии и графический интерфейс, почтовый сервис и другие.

Каждый компонент соединен с другим через ряд открытых «портов». Для каждого внешнего компонента существует «адаптер», который преобразует определение API в сигналы, необходимые этому компоненту, и наоборот. Как адаптеру могут обратиться любыми средствами, например веб-сервисом, вызовом метода в языке программирования или удаленным вызовом процедур. Любой порт может иметь несколько адаптеров. Адаптеры могут быть взаимозаменяемыми с обеих сторон, не затрагивая бизнес-логику. Это позволяет легко масштабировать решение для использования новых интерфейсов или технологий.

Ядро проекта с гексагональной архитектурой представлено как минимум тремя видами компонентов:

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

Пример

Например, в приложении для кофейни может быть пользовательский интерфейс кассы, который обрабатывает прием заказов на кофе. Когда бариста отправляет заказ, REST-адаптер принимает HTTP-запрос POST и преобразует его в форму, понятную порту. При вызове порта запускается бизнес-логика, связанная с оформлением заказа внутри приложения. Само приложение не знает, что оно работает через REST API.

Далее приложение взаимодействует с портом, который позволяет сохранять заказы. Так как в примере мы используем реляционную базу данных, то подключение к ней было реализовано через адаптер базы данных. Адаптер принимает информацию, поступающую из порта, и преобразует её в SQL-запрос для хранения заказа в базе данных. Само приложение не знает, как реализован данный функционал, и какие технологии при этом используются.

Эволюция и альтернативы

По мнению некоторых авторов, гексагональная архитектура лежит в основе микросервисов.^[2]

Луковичная архитектура, предложенная Джеффри Палермо в 2008 году, похожа на гексагональную архитектуру: она также выводит компоненты за пределы ядра проекта, чтобы обеспечить слабую связь между приложением и базой данных. Далее ядро приложения разбивается на несколько концентрических колец с помощью инверсии управления.

Чистая архитектура^[3], предложенная Робертом Мартином в 2012 году, сочетает в себе принципы гексагональной архитектуры, луковичной архитектуры и нескольких других вариантов. Она обеспечивает дополнительные уровни детализации компонента, которые представлены в виде концентрических колец. Он изолирует адаптеры и интерфейсы (пользовательский интерфейс, базы данных, внешние системы, устройства) во внешних кольцах архитектуры и оставляет внутренние кольца для разныхсценариев использования. Чистая архитектура использует принцип инверсии зависимостей со строгим правилом, согласно которому зависимости должны существовать только между внешним кольцом и внутренним кольцом и никогда наоборот.

Смотрите также

Ссылки

↑ Hexagonal architecture (англ.).
↑ Rajesh R. V. Spring 5.0 microservices : build scalable microservices with Reactive Streams, Spring Boot, Docker, and Mesos (англ.). — Packt Publishing, 2017. — P. 13-14. — ISBN 978-1-78712-051-8.
↑ Роберт Мартин. Чистая архитектура. Искусство разработки программного обеспечения (рус.). — СПб.: ПИТЕР, 2019. — 352 с.

[1] Hexagonal architecture (англ.).

[2] Rajesh R. V. Spring 5.0 microservices : build scalable microservices with Reactive Streams, Spring Boot, Docker, and Mesos (англ.). — Packt Publishing, 2017. — P. 13-14. — ISBN 978-1-78712-051-8.

[3] Роберт Мартин. Чистая архитектура. Искусство разработки программного обеспечения (рус.). — СПб.: ПИТЕР, 2019. — 352 с.

[1]

[2]

[3]