Hexagonale Architektur

Beispiel einer Sechseck-Architektur

Der Ausdruck „hexagonal“ leitet sich von der grafischen Konvention zur Darstellung der Ports-und-Adapter-Architektur ab. Nicht alle Kanten der geometrischen Figur müssen zur Darstellung von Adapter und Ports benutzt werden, aber sie sollen möglichen zusätzlichen Schnittstellen der Komponente zu ihrer Außenwelt genug Raum für ihre Darstellung geben.[1]

Die hexagonale Architektur unterteilt das System in verschiedene, lose gekoppelte und untereinander austauschbare Komponenten, wie den Anwendungskern, die Datenbank, die Benutzerschnittstelle, Testskripte und Schnittstellen mit anderen Systemen. Dieser Ansatz ist eine Alternative zur etablierten Schichtenarchitektur.

Jede Komponente ist mit den anderen mittels exponierter Ports verbunden. Kommunikation durch diese Ports folgen einem definierten Protokoll, abhängig von ihrem Zweck. Ports und Protokolle definieren eine abstrakte API, die von jedem technischen Mittel implementiert werden kann, wie zum Beispiel Unterprogrammaufrufen in einer objektorientierten Programmiersprache, Remote Procedure Calls, oder Webservices.

Die Feingliedrigkeit der Ports und ihre Zahl ist nicht beschränkt:

• ein einziger Port kann in einigen Fällen ausreichend sein (beispielsweise im Fall eines einzigen Dienstbenutzers oder einem geöffneten Port über HTTP, z. B. WebSockets)
• typischerweise gibt es Ports für Ereignisquellen (wie Benutzerschnittstellen), Persistenz oder Datenbank (um die Komponente mit einem passenden DBMS kommunizieren zu lassen), Benachrichtigung und Verwaltung (zur Steuerung der Komponente)
• in extremen Fällen kann es auch einen Port für jeden Anwendungsfall geben, falls erforderlich

Adapter verkleben die Komponente mit dem Umfeld. Sie schneiden den Datenaustausch zwischen dem Umfeld und den Ports, welche die Anforderungen an den Kern der Komponente repräsentieren, passgenau zu. Es kann auch mehrere Adapter für einen Port geben. Beispielsweise können Daten von einem Nutzer per GUI oder CLI angeboten werden, oder durch eine automatisierte Datenquelle wie Datenbanken oder Polling Services oder durch Testskripte als Fixtur.

Der Ausdruck „hexagonal“ unterstellt, dass es sechs Teile des Konzepts geben muss, während es in Wirklichkeit nur vier Schlüsselfelder gibt: Benachrichtigung, Persistenz (Speicherung), Geschäftsereignisse, Verwaltung.[2]

Nach Martin Fowler hat die Sechseck-Architektur den Vorteil, Ähnlichkeiten zwischen Präsentationsschicht und Datenquellschicht zu nutzen, um symmetrische Komponenten zu schaffen, die aus einem Kern und einem Ring an Schnittstellen gebaut wurden, doch mit dem Nachteil, dass die innewohnende, natürliche Asymmetrie zwischen Dienstanbietern und Dienstbenutzern verborgen wird, die durch Schichten besser repräsentiert werden würden.[3] Beispielsweise kann der Dienstbenutzer nie mehr Daten verarbeiten, als der Dienstanbieter bereitstellt, während der Dienstanbieter durch viel umfangreicheres Wissen grundsätzlich in der Lage ist, nicht nur die vom Dienstbenutzer benötigten, sondern all seine Daten in beliebiger Form bereitzustellen. In einer Sechseck-Architektur wird unterstellt, dass sich die Komponenten ihr Wissen und ihre Daten gleichberechtigt teilen.

Die hexagonale Architektur wurde von Alistair Cockburn erfunden, um strukturelle Fallstricke in objektorientiertem Softwaredesign, wie unerwünschte Abhängigkeiten zwischen den Schichten oder die Verunreinigung von Code zur Benutzerschnittstelle mit Geschäftslogik zu umgehen. Er veröffentlichte sein Konzept im Jahr 2005.[4]

Das Architekturmuster Model View Controller (MVC) wurde 1979 von Trygve Reenskaug eingeführt. Es ist ein Muster zur Unterteilung einer Software in die drei Komponenten Datenmodell, Ansicht und Programmsteuerung,[5] damit spätere Änderung, Erweiterung und Wiederverwendbarkeit möglich wird.

Der Entity-Control-Boundary-Ansatz (ECB) wurde 1992 von Ivar Jacobson im Rahmen seines OOSE (engl. Object-Oriented Software Engineering) Softwareentwicklungsprozesses veröffentlicht.[6][7] In diesem Architekturmuster regeln Einschränkungen, dass Entity-Klassen nur mit Control-Klassen kommunizieren dürfen, und Control-Klassen nur mit Boundarie-Klassen, die nichts über andere Boundary-Klassen wissen.

Die Zwiebelarchitektur von Jeffrey Palermo aus dem Jahr 2008 ist ähnlich der Sechseck-Architektur: es veräußert ebenfalls die Infrastruktur mit Schnittstellen, um lose Kopplung zwischen Applikation und Datenbank zu sichern.[8] Ferner zerlegt es den Anwendungskern in verschiedene konzentrische Ringe durch die Verwendung des Musters Inversion of Control.[9] Es ist eine Software-Architektur, die in der objektorientierten Programmierung verwendet wird und die Klassen, aus denen sich der objektorientierte High-Level-Quellcode zusammensetzt, entsprechend ihrer Verantwortlichkeiten bei der Realisierung des Anwendungsfalls strukturiert.

Die Clean Architecture, wie von Robert C. Martin 2012 vorgeschlagen, kombiniert die Prinzipien der sechseckigen, der Zwiebel- und weiterer Architekturen. Sie bietet zusätzliche Ebenen Ausführlichkeit der Komponenten, welche ebenfalls als konzentrische Ringe präsentiert werden. Es isoliert Adapter und Schnittstellen (Benutzerschnittstellen, Datenbanken, externe Systeme und Geräte) in äußere Ringe der Architektur und belässt die inneren Ringe den Anwendungsfällen und Entitäten.[10][11] Die Clean Architecture nutzt das Prinzip der Dependency Inversion mit der strikten Regel, dass Abhängigkeiten nur von einem außen liegenden Ring zu seinem nächsten, innen liegenden Ring bestehen sollten, und niemals umgekehrt.

Nach Meinung einzelner Autoren ist die Sechseck-Architektur der Ursprung der Microservice-Architektur.[12]

• Architekturmuster
• Schichtenarchitektur
• Kompositionsstrukturdiagramm
• Objektorientierte Analyse und Design

1. Alistair Cockburn: Hexagonal architecture. In: alistair.cockburn.us. 1. April 2005, abgerufen am 18. November 2020 (englisch).
2. Alistair Cockburn: Hexagonal architecture. In: alistair.cockburn.us. 1. April 2005, abgerufen am 18. November 2020 (englisch).
3. Martin Fowler: Patterns of enterprise application architecture. Hrsg.: Addison-Wesley, Boston. Addison-Wesley, Boston, Massachusetts (USA) 2003, OCLC 50292267.
4. Jan Stenberg: Exploring the Hexagonal Architecture. In: InfoQ. 31. Oktober 2014, abgerufen am 12. August 2019 (englisch).
5. Kamal Wickramanayake: Is MVC a design pattern or an architectural pattern? In: Software View. 17. Juli 2010, abgerufen am 16. Dezember 2016 (englisch).
6. Jacobson, Ivar.: Object-oriented software engineering: a use case driven approach. ACM Press, [New York] 1992, ISBN 0-201-54435-0, S. 130–133 (englisch, archive.org).
7. Reading notice on Object Oriented Software Engineering, Ivar Jacobson, et al. (1992). In: tedfelix.com. Abgerufen am 14. August 2019 (englisch).
8. Palermo Jeffrey: The Onion Architecture : part 1. In: Programming with Palermo. 29. Juli 2008, abgerufen am 12. August 2019 (amerikanisches Englisch).
9. Suhas Chatekar: Learning NHibernate 4 : explore the full potential of NHibernate to build robust data access code. Packt Publishing, Birmingham, Birmingham, UK 2015, OCLC 937787252.
10. Robert, C. Martin: The Clean architecture | Clean Coder Blog. In: blog.cleancoder.com. 12. August 2012, abgerufen am 12. August 2019 (englisch).
11. Robert Martin: Clean Architecture : a Craftsman's Guide to Software Structure and Design, First Edition. Prentice Hall, 2017, ISBN 978-0-13-449416-6.
12. Rajesh R V: Spring 5.0 Microservices: build scalable microservices with Reactive Streams, Spring Boot, Docker, and Mesos. Hrsg.: Packt Publishing, Birmingham. 2. Auflage. Packt Publishing, Birmingham, UK 2017, OCLC 999610958.