Гексагональна архітектура (програмування)

Гексагональна архітектура, або архітектура портів та адаптерів, є прикладом архітектури, що використовується при розробці програмного забезпечення. Вона спрямована на створення слабкозв'язних компонентів застосувань, які можна легко підключити до програмного середовища за допомогою портів та адаптерів. Це робить компоненти легкозамінними на будь-якому рівні та полегшує автоматизацію тестування.[1]

Походження

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

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

Принцип

Example of hexagonal architecture with an inner hexagon representing the application core, and an outer hexagon for the adapters, the border between the two being the ports
Приклад гексагональної архітектури

Гексагональна архітектура розділяє систему на декілька вільнопов'язаних взаємозамінних компонентів, таких як ядро програми, база даних, користувальницький інтерфейс, тестові скрипти та інтерфейси з іншими системами. Цей підхід є альтернативою традиційній багатошаровій архітектурі.

Кожен компонент з'єднаний з іншими через безліч відкритих «портів». Зв'язок через ці порти здійснюється за певним протоколом залежно від їх призначення. Порти та протоколи визначають абстрактний API, який може бути реалізований будь-якими відповідними технічними засобами (наприклад, виклик методу об'єктно-орієнтованою мовою, віддалені виклики процедур або вебслужби).

Деталізованість портів та їх кількість не обмежена:

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

Адаптери — це міст, що поєднує компоненти та зовнішній світ. Вони адаптують обмін між зовнішнім світом та портами, що відповідають вимогам внутрішньої частини компонента програми. Для одного порту може бути кілька адаптерів, наприклад, якщо дані можуть бути надані користувачем через графічний інтерфейс або інтерфейс командного рядка, через автоматизоване джерело даних або за допомогою тестових скриптів.

Критика

За словами Мартіна Фаулера, гексагональна архітектура має перевагу використання і схожості між шаром презентації та рівнем джерела даних для створення симетричних компонентів, виготовлених із ядра, оточеного інтерфейсами, але з недоліком приховування властивої асиметрії між постачальником послуг та споживачем послуги. Цей недолік можна було б виправити, якщо представити у вигляді шарів.[3]

На думку деяких авторів, гексагональна архітектура базована на основі мікросервісної[4] архітектури.

Варіанти

Цибулева архітектура, запропонована Джеффрі Палермо в 2008 році, схожа на шестигранну архітектуру: вона також дає можливість зовнішнього існування інфраструктури з належними інтерфейсами для забезпечення вільного зв'язку між додатком та базою даних.[5] Він додатково розкладає серцевину додатка на кілька концентричних кілець за допомогою інверсії керування.[6]

Чиста архітектура, запропонована Робертом К. Мартіном у 2012 році, поєднує принципи гексагональної архітектури, цибулевої архітектури та декількох інших варіантів. Вона забезпечує додаткові рівні деталізації компонента, які представлені у вигляді концентричних кілець. Це ізолює адаптери і інтерфейси (призначений для користувача інтерфейс, бази даних, зовнішні системи, пристрій) в зовнішніх кільцях архітектури і залишає внутрішні кільця для варіантів використання і бізнес-правил рівня підприємства[7][8]. Чиста архітектура використовує принцип інверсії залежностей із суворим правилом, згідно з яким залежності повинні існувати лише між зовнішнім кільцем та внутрішнім кільцем, а ніколи не навпаки.

Див. також

Список літератури

  1. ↑ а б Alistair, Cockburn (1 квітня 2005). Hexagonal architecture. alistair.cockburn.us. Архів оригіналу за 1 листопада 2020. Процитовано 18 листопада 2020.
  2. ↑ Stenberg, Jan (31 жовтня 2014). Exploring the Hexagonal Architecture. InfoQ. Архів оригіналу за 3 грудня 2020. Процитовано 12 серпня 2019.
  3. ↑ Fowler, Martin (2003). Patterns of enterprise application architecture. Addison-Wesley. с. 21. ISBN 0-321-12742-0. OCLC 50292267.
  4. ↑ Rajesh R. V. (2017). Spring 5.0 microservices : build scalable microservices with Reactive Streams, Spring Boot, Docker, and Mesos (вид. Second). Packt Publishing. с. 13—14. ISBN 978-1-78712-051-8. OCLC 999610958.
  5. ↑ Jeffrey, Palermo (29 липня 2008). The Onion Architecture : part 1. Programming with Palermo (амер.). Архів оригіналу за 11 листопада 2020. Процитовано 12 серпня 2019.
  6. ↑ Chatekar, Suhas (2015). Learning NHibernate 4 : explore the full potential of NHibernate to build robust data access code. Packt Publishing. с. 249—250. ISBN 978-1-78439-206-2. OCLC 937787252.
  7. ↑ Martin, Robert, C. (12 серпня 2012). The Clean architecture | Clean Coder Blog. blog.cleancoder.com. Архів оригіналу за 3 грудня 2020. Процитовано 12 серпня 2019.
  8. ↑ Martin, Robert C. (2017). Clean architecture: a craftsman's guide to software structure and design. Prentice Hall. ISBN 978-0-13-449416-6. OCLC 1004983973.