Гексагональная архитектура представляет собой архитектурный паттерн, который используется при разработке программного обеспечения. Основная цель этой архитектуры - отделить основную логику приложения от сервисов, которые оно использует. Это позволит «подключать» различные сервисы и запускать приложение без этих сервисов, а также упростит написание автоматизированных тестов.
Появление Гексагональная архитектура была представлена Алистером Кокберном у него в блоге в 2005 году в попытке избежать известных структурных ошибок в объектно-ориентированном проектировании программного обеспечения, таких как нежелательные зависимости между бизнес-логикой и пользовательским интерфейсом.
Термин «гексагональный» происходит от графического обозначения этой архитектуры, согласно которому ядро проекта изображается в виде шестиугольной ячейки. Главной целью у гексагональной архитектуры является отделение компонентов, входящими в ядро проекта от компонентов, к нему не относящимся. К ядру программы, например, не относятся контроллеры, репозитории или презентаторы. Все они в гексагональной архитектуре относятся к инфраструктурным компонентам.
Принцип работы
Гексагональная архитектура делит программное обеспечение на несколько слабосвязанных компонентов: ядро проекта, база данных, пользовательский интерфейс, тестовые сценарии и графический интерфейс, почтовый сервис и другие.
Каждый компонент соединен с другим через ряд открытых «портов». Для каждого внешнего компонента существует «адаптер», который преобразует определение API в сигналы, необходимые этому компоненту, и наоборот. Как адаптеру могут обратиться любыми средствами, например веб-сервисом, вызовом метода в языке программирования или удаленным вызовом процедур. Любой порт может иметь несколько адаптеров. Адаптеры могут быть взаимозаменяемыми с обеих сторон, не затрагивая бизнес-логику. Это позволяет легко масштабировать решение для использования новых интерфейсов или технологий.
Ядро проекта с гексагональной архитектурой представлено как минимум тремя видами компонентов:
Управляющими портами, при помощи которых объявляются открытые API ядра. Адаптерами управляющих портов, которые реализуют логику ядра проекта. Управляемыми портами, при помощи которых ядро может обращаться к внешним компонентам: базам данных, очередям сообщений, почтовым серверам и т.д.
Пример
Например, в приложении для кофейни может быть пользовательский интерфейс кассы, который обрабатывает прием заказов на кофе. Когда бариста отправляет заказ, REST-адаптер принимает HTTP-запрос POST и преобразует его в форму, понятную порту. При вызове порта запускается бизнес-логика, связанная с оформлением заказа внутри приложения. Само приложение не знает, что оно работает через REST API.
Далее приложение взаимодействует с портом, который позволяет сохранять заказы. Так как в примере мы используем реляционную базу данных, то подключение к ней было реализовано через адаптер базы данных. Адаптер принимает информацию, поступающую из порта, и преобразует её в SQL-запрос для хранения заказа в базе данных. Само приложение не знает, как реализован данный функционал, и какие технологии при этом используются.
Эволюция и альтернативы По мнению некоторых авторов, гексагональная архитектура лежит в основе микросервисов.
Луковичная архитектура, предложенная Джеффри Палермо в 2008 году, похожа на гексагональную архитектуру: она также выводит компоненты за пределы ядра проекта, чтобы обеспечить слабую связь между приложением и базой данных. Далее ядро приложения разбивается на несколько концентрических колец с помощью инверсии управления.
Чистая архитектура, предложенная Робертом Мартином в 2012 году, сочетает в себе принципы гексагональной архитектуры, луковичной архитектуры и нескольких других вариантов. Она обеспечивает дополнительные уровни детализации компонента, которые представлены в виде концентрических колец. Он изолирует адаптеры и интерфейсы (пользовательский интерфейс, базы данных, внешние системы, устройства) во внешних кольцах архитектуры и оставляет внутренние кольца для разных сценариев использования. Чистая архитектура использует принцип инверсии зависимостей со строгим правилом, согласно которому зависимости должны существовать только между внешним кольцом и внутренним кольцом и никогда наоборот.
См. также
Шаблоны проектирования Объектно-ориентированное проектирование
Ссылки
Категория:Шаблоны проектирования Категория:Программирование