Suchen

Ports and Adapters – Eine Software-Architektur für moderne Applikationen

Seite: 2/2

Firmen zum Thema

Vorgehen und Vorteile von „Ports and Adapters“

Beim Entwurf von Anwendungen nach dem „Ports and Adapters“-Muster beginnt man üblicherweise mit der Definition der einzelnen Ports.Eine „klassisch aufgebaute“ Anwendung mit Datenhaltung, Geschäftslogik und Benutzeroberfläche besitzt zunächst, vereinfacht dargestellt, zwei Ports: zum einen den Benutzer- und zum anderen den Datenhaltungsport.

Aber welche Adapter soll es geben? Und wie lassen sie sich identifizieren? Der Benutzer soll die Anwendung durch eine HTML-Oberfläche steuern können. Anderen Clients bzw. Tests sollen die Möglichkeit haben unsere Anwendung mittels einer REST-Schnittstelle zu steuern. Die Daten der Anwendung sollen in einer Postgres-Datenbank gespeichert werden können. Und zu Testzwecken soll es möglich sein die Anwendung ohne eine Datenbank zu betreiben.

Bildergalerie

Daraus ergeben sich effektiv vier Adapter, die Sie der entsprechenden Abbildung entnehmen können (siehe „Systemaufbau im Überblick“). Im Anschluss an die Definition der Adapter und Ports werden deren Schnittstellen beschrieben. Dies kann entweder in UML geschehen oder direkt durch die Erstellung von Interfaces, wie man sie aus C# oder Java kennt.

Nach dem Entwurf der einzelnen Ports beginnt man mit der Implementierung. Entscheidender Vorteil: Die Implementierung der Adapter kann ab diesem Zeitpunkt parallel erfolgen, denn die Subsysteme der Anwendung kommunizieren nur über die zuvor definierten Ports. Daraus ergeben sich folgende Vorteile.

Welche Vorteile hat die Softwarearchitektur Ports and Adapters?

1. Klare Einteilung der Komponenten: Der Einsatz des Patterns führt zu einer eindeutigen Einteilung der unterschiedlichen Komponenten. Alle Objekte, die beispielsweise für die Darstellung der Anwendung gebraucht werden, existieren lediglich im entsprechenden GUI-Adapter, während die für die Kommunikation mit der Datenbank notwendigen Objekte nur dem Datenbankadapter bekannt sind.

2. Eine Anwendung in mehreren Ausprägungen: Ähnlich wie in einem Baukastenprinzip lassen sich in der Hexagonalen Architektur verschiedene Varianten einer Anwendung zusammenfügen. So wäre es denkbar den Postgres-Datenbank-Adapter durch einen Android-SQLite-Adapter und den HTML-UI-Adapter durch einen nativen Android-UI-Adapter zu ersetzen. Mit dem Austausch von lediglich zwei Komponenten wandelt man die Anwendung zu einer nativen Android-Anwendung, ohne dass die eigentliche Geschäftslogik geändert werden muss.

3. Parallele Entwicklung: Die klare Einteilung in Komponenten und in wohldefinierten Schnittstellen ermöglicht es verschiedenen Teams oder Einzelpersonen parallel an der jeweiligen Implementierung zu arbeiten. Zum Zeitpunkt des Entwicklungsstarts ist es einfach das Verhalten noch fehlender Komponenten mit „Test-Adaptern“ zu simulieren. So muss man nicht auf die Fertigstellung etwa der Datenhaltungsschicht warten.

4. Austauschbarkeit der Adapter:Sollte es notwendig sein Funktionalität auszutauschen, beispielsweise das Datenbanksystem zu ersetzen, darf sich aus Anwendungssicht nicht zwangsweise auch das Protokoll zwischen der Anwendung und der Datenhaltungskomponente ändern. Durch den Einsatz von „Ports and Adapters“ kann man dieses Risiko minimieren. Adapter sind leicht austauschbar; daher ist ein Wechsel zwischen Datenbanken nichts weiter als ein Wechsel des entsprechenden Adapters.

5. Einfache Erweiterbarkeit und Skalierbarkeit: Durch das konsequente Entwickeln gegen Ports lässt sich die grundlegende Adapterstruktur leicht ändern. So wäre es denkbar die einzelnen Adapter des Systems als Microservices zu realisieren. Ohne größeren Aufwand ist es so möglich eine Anwendung von einem lokalem zu einem verteilten System zu migrieren.

6. Keine Festlegung auf eine Zulieferform: Da die Hexagonale Architektur keinerlei Annahmen über die Darstellung der Daten und die Entgegennahme der Benutzereingaben trifft, ist man folglich an dieser Stelle auch nicht festgelegt. Hat man seine Anwendung ursprünglich als schichtenbasierte Webanwendung entworfen, so ist es mitunter schwer ihre Funktionalität einer mobilen Anwendung zur Verfügung zu stellen. Im Falle der Hexagonalen Architektur stellt die mobile Anwendung nur einen weiteren Adapter für die Entgegennahme der Benutzereingaben dar.

7. Keine Festlegung auf eine Architekturform innerhalb der einzelnen Komponenten: Innerhalb der Hexagonalen Architektur werden keinerlei Annahmen über den Entwurf der einzelnen Adapter getroffen. Um beispielsweise eine webbasierte Oberfläche als Adapter für die Benutzerinteraktion zu entwickeln, kann man sich problemlos eines Musters für die Oberflächenentwicklung, wie etwa MVC (Model-View-Controller), bedienen.

Höhere Komplexität und Orchestrierung der Anwendung

Wie jede Architekturentscheidung bringt auch die Hexagonale Architektur Nachteile mit sich. Zum Einen resultiert die Implementierung in einer höheren Komplexität: Durch den Einsatz jeder Abstraktion erhöht sich zwangsläufig die Komplexität der betroffenen Anwendung. Anders als bei einer monolithischen Anwendung befinden sich die einzelnen Komponenten des Gesamtsystems mitunter nicht mehr an einem Ort. Möglicherweise sind sie über mehrere Projekte und Subprojekte verteilt, was dazu führt, dass sich neue Kollegen zunächst mit der Orientierung etwas schwerer tun.

Zum Anderen wird eine Orchestrierung der Anwendung notwendig. Um die einzelnen Teile der Anwendung zusammenzufügen, bedarf es einer Komponente für diese Aufgabe. Diese kann ihrer Aufgabe manuell oder per Dependency Injection nachkommen. Letzteres wiederum erhöht die Komplexität zusätzlich.

Die Hexagonale Architektur hat wie jedes Architekturmuster ihren Preis und mag sich für sehr kleine Projekte nicht lohnen. Ist jedoch abzusehen, dass es sich bei einer neu zu entwickelnden Anwendung um mehr als nur einen Prototyp handelt oder dass sie über einen langen Zeitraum im Einsatz sein wird, lohnt sich die Investition sicherlich.

Erfahrungsgemäß eignet sich das Muster in der Praxis hervorragend und bereitet dem Schichtensalat erfolgreich ein Ende. Nicht nur lassen sich Anwendungen ganzheitlich und in Teilen sehr einfach testen, das Muster ist auch eine echte Investition in die Wart- und Erweiterbarkeit der zu entwickelnden Anwendung.

Man möchte eines schönen Tages seine bisherige Desktopanwendung auch im Web, auf Smartphones oder Tabletts anbieten? Wohl dem, dessen Anwendung nach „Ports and Adapters“ entwickelt wurde - die brandneue mobile Anwendung ist nur wenige neue Adapter entfernt.

* Benjamin Klüglein ist Senior Software Engineer bei Method Park

(ID:44950719)