Гексагональная архитектура или другое название "Порты и адаптеры" ("Ports and adapters architecture") - это архитектурный шаблон, направленные на создание слабо связанных компонентов приложений. Компоненты подключаются к программной среде с помощью портов и адаптеров. Слабая связанность позволяет реализовать еще одно преимущество - взаимозаменяемость компонент.
Гексагональная архитектура была изобретена Алистером Кокберном в попытке избежать структурных ошибок в объектно-ориентированном проектировании программного обеспечения. В частности, нежелательной зависимости между уровнями ПО и загрязнения уровня пользовательского интерфейса кодом, реализующим бизнес-логику.
Термин «гексагональный» следует из графики программной среды. Цель же шестиугольника не в подчеркивании границ, а в том, чтобы зарезервировать достаточно места для последующего развития данной архитектуру в части отражения взаимодействия программ с внешним миром. Поэтому, не обязательно следовать шаблону шестиугольника и можно увидеть восьмиугольники для представления тех же идей "шестиугольной архитектуры".
Пример DDD, Hexagonal, Onion, Clean, CQRS… как я собрал всё это вместе
Гексагональная архитектура делит систему на несколько слабо связанных взаимозаменяемых компонентов, таких как ядро приложения, база данных, пользовательский интерфейс, тестовые сценарии и интерфейсы с другими системами. Такой подход является альтернативой традиционной многоуровневой архитектуре.
Каждый компонент подключен к другим через ряд открытых «портов». Связь через эти порты осуществляется по заданному протоколу в зависимости от их назначения. Порты и протоколы определяют абстрактный API, который может быть реализован подходящими техническими средствами, посредством метода, удаленного вызова процедур или использованя веб-службы.
Гранулярность портов и их количество не ограничено. Адаптеры связывают программные компоненты с внешним миром. Для одного порта может быть несколько адаптеров.
По словам Мартина Фаулера , преимуществом гексагональной архитектуры является использование сходства между уровнем представления и уровнем источника данных для создания симметричных компонентов, состоящих из ядра, окруженного интерфейсами, но с недостатком сокрытия внутренней асимметрии между поставщиком услуг и потребителем услуг.
По мнению некоторых, гексагональная архитектура лежит в основе архитектуры микросервисов. Луковая архитектура (The onion architecture), предложенная Джеффри Палермо в 2008 году, похожа на гексагональную архитектуру.
Чистая архитектура, предложенная Робертом К. Мартином в 2012 году, сочетает в себе принципы шестиугольной архитектуры, луковой архитектуры и нескольких других вариантов (https://herbertograca.com/2017/09/28/clean-architecture-standing-on-the-shoulders-of-giants/).
Надо сказать, что подобные архитектурные ухищрения полезны и позитивно сказываются на поддержке ПО и сокращении технологического долга.
В заключении стоит сказать - о какой поддержке идет речь: какого типа поддерживаемость мы хотим получить? Какие метрики могут сказать нам что мы имеем высокую поддерживаемость нашего приложения?
Ответ состоит в следующем:
- Изменения в одной части приложения должно затрагивать как можно меньше других частей.
- Добавление нового функционала не должно требовать масштабных изменений в коде.
- Организация нового интерфейса для взаимодействия с приложением должно приводить к минимально возможным изменениям приложения.
- Отладка должна включать как можно меньше временных решений и хаков.
- Тестирование должно происходить относительно легко.
И для этого тоже разрабатываются архитектуры.
Комментариев нет:
Отправить комментарий