|
Hexagonale ArchitekturDie hexagonale Architektur, Sechseck-Architektur oder Ports-und-Adapter-Architektur, ist ein Architekturmuster im Softwaredesign. Ihr Ziel ist die Entwicklung lose gekoppelter Anwendungskomponenten, die mit Ports und Adaptern (generell auch sonstigen Interfaces) einfach mit ihrem Software-Umfeld verbunden werden können. Auf diese Weise wird eine höhere Austauschbarkeit erreicht und die Ausführung automatischer Software-Tests ermöglicht.[1] Prinzip 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:
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. RezeptionDer 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. UrsprungDie 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] VorläuferDas 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. VariantenDie 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. WeiterentwicklungNach Meinung einzelner Autoren ist die Sechseck-Architektur der Ursprung der Microservice-Architektur.[12] Siehe auch
Belege
|