Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

Гексагональная архитектура или порты и адаптеры архитектуры , архитектурный шаблон используется в разработке программного обеспечения . Он направлен на создание слабосвязанных компонентов приложений, которые можно легко подключить к их программной среде с помощью портов и адаптеров . Это делает компоненты взаимозаменяемыми на любом уровне и упрощает автоматизацию тестирования. [1]

Происхождение [ править ]

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

Термин «гексагональный» происходит от графических соглашений, которые показывают компонент приложения как гексагональную ячейку. Цель заключалась не в том, чтобы предложить шесть границ / портов, а в том, чтобы оставить достаточно места для представления различных интерфейсов, необходимых между компонентом и внешним миром. [1]

Принцип [ править ]

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

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

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

Гранулярность портов и их количество не ограничены:

  • в некоторых случаях может быть достаточно одного порта (например, в случае простого потребителя услуг);
  • обычно есть порты для источников событий (пользовательский интерфейс, автоматическая подача), уведомлений (исходящие уведомления), базы данных (для взаимодействия компонента с любой подходящей СУБД) и администрирования (для управления компонентом);
  • в крайнем случае, при необходимости может быть другой порт для каждого варианта использования .

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

Критика и эволюция [ править ]

  • Критика

Термин «гексагональный» подразумевает, что концепция состоит из 6 частей, тогда как ключевых областей всего 4. Использование этого термина происходит из графических соглашений, которые показывают компонент приложения как шестиугольную ячейку. Цель заключалась не в том, чтобы предложить шесть границ / портов, а в том, чтобы оставить достаточно места для представления различных интерфейсов, необходимых между компонентом и внешним миром. [3]


По словам Мартина Фаулера , преимуществом гексагональной архитектуры является использование сходства между уровнем представления и уровнем источника данных для создания симметричных компонентов, состоящих из ядра, окруженного интерфейсами, но с недостатком скрытия внутренней асимметрии между поставщиком услуг и потребителем услуг. это лучше было бы представить в виде слоев. [4]

  • Эволюция

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

  • Критика

Варианты [ править ]

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

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

См. Также [ править ]

  • Шаблоны архитектуры
  • Слой (объектно-ориентированный дизайн)
  • Схема составной структуры
  • Объектно-ориентированный анализ и дизайн

Ссылки [ править ]

  1. ^ a b Алистер, Кокберн (1 апреля 2005 г.). «Шестиугольная архитектура» . alistair.cockburn.us . Проверено 18 ноября 2020 .
  2. Перейти ↑ Stenberg, Jan (2014-10-31). «Изучение шестиугольной архитектуры» . InfoQ . Проверено 12 августа 2019 .
  3. ^ Алистер, Кокберн (2005-04-01). «Шестиугольная архитектура» . alistair.cockburn.us . Проверено 18 ноября 2020 .
  4. ^ Фаулер, Мартин (2003). Паттерны архитектуры корпоративных приложений . Эддисон-Уэсли. п. 21. ISBN 0-321-12742-0. OCLC  50292267 .
  5. Перейти ↑ Rajesh RV (2017). Микросервисы Spring 5.0: создавайте масштабируемые микросервисы с помощью Reactive Streams, Spring Boot, Docker и Mesos (второе изд.). Packt Publishing. С. 13–14. ISBN 978-1-78712-051-8. OCLC  999610958 .
  6. ^ Джеффри, Палермо (2008-07-29). «Луковая архитектура: часть 1» . Программирование с Палермо . Проверено 12 августа 2019 .
  7. ^ Chatekar, Suhas (2015). Изучение NHibernate 4: исследуйте весь потенциал NHibernate для создания надежного кода доступа к данным . Packt Publishing. С. 249–250. ISBN 978-1-78439-206-2. OCLC  937787252 .
  8. ^ Мартин, Роберт, К. (2012-08-12). "Чистая архитектура | Блог чистого кодера" . blog.cleancoder.com . Проверено 12 августа 2019 .
  9. ^ Мартин, Роберт С. (2017). Чистая архитектура: руководство по структуре и дизайну программного обеспечения . Прентис Холл. ISBN 978-0-13-449416-6. OCLC  1004983973 .