Der Begriff Hexagonale Architektur stammt von Alistair Cockburn und ist nicht mehr ganz neu. Er wendet die gleichen Prinzipien an, die Robert C. Martin später in allgemeineren Worten in Clean Architecture beschrieben hat.
Die Abbildung zeigt, wie eine Hexagonale Architektur aussehen könnte. Der Kern der Anwendung ist als Sechseck (Hexagon) dargestellt – daher der Name des Architekturstils. Die Sechseckform hat keine besondere Bedeutung; Sie könnten auch ein Achteck zeichnen und das Ganze »Oktagonale Architektur« nennen. Angeblich wurde das Sechseck einfach nur deshalb anstelle eines gewöhnlichen Vierecks benutzt, um zu zeigen, dass eine Anwendung mehr als vier Seiten haben kann, die sie mit anderen Systemen oder Adaptern verbindet.
Innerhalb des Sechsecks finden Sie Ihre Domänen-Entities und die Use Cases, die mit diesen Entities zusammenarbeiten. Wie Sie sehen, hat das Sechseck keine nach außen gehenden Abhängigkeiten. Die Abhängigkeitsregel aus Martins Clean Architecture wird also befolgt. Alle Abhängigkeiten weisen stattdessen nach innen.
Außerhalb des Sechsecks finden Sie verschiedene Adapter, die mit der Anwendung interagieren. Es könnte einen Web-Adapter geben, der die Verbindung zu einem Webbrowser herstellt, einige Adapter, die mit externen Drittsystemen interagieren, sowie einen Adapter, der die Zusammenarbeit mit einer Datenbank erlaubt, um eine persistente Ablage der Daten zu gewährleisten.
Die Adapter auf der linken Seite dienen zum »Antreiben« Ihrer Anwendung (»driving adapters«, weil sie Ihren Anwendungskern aufrufen), während die Adapter auf der rechten Seite von Ihrer Anwendung getrieben werden (»driven adapters«, weil sie vom Anwendungskern aufgerufen werden).
Um eine Kommunikation zwischen dem Anwendungskern und den Adaptern zu erlauben, stellt der Anwendungskern spezielle Ports zur Verfügung. Für treibende Adapter könnte ein solcher Port eine Schnittstelle sein, die von einer der UseCase-Klassen im Kern implementiert und vom Adapter aufgerufen wird. Für einen getriebenen Adapter könnte es eine Schnittstelle sein, die vom Adapter implementiert und vom Kern aufgerufen wird. Es könnte sogar mehrere Adapter geben, die denselben Port implementieren: zum Beispiel einen zum Kommunizieren mit einem realen externen System und einen zum Kommunizieren mit einem Mock, der bei Tests zum Einsatz kommt.
Um eine zentrale Eigenschaft der Hexagonalen Architektur deutlich zu machen: Der Anwendungskern (das Sechseck) definiert und besitzt die Schnittstelle nach außen (die Ports). Die Adapter arbeiten dann mit dieser Schnittstelle zusammen. Hier wird das Dependency-Inversion-Prinzip auf der Ebene der Architektur angewandt. Aufgrund seiner zentralen Konzepte ist dieser Architekturstil auch als Ports-und Adapter-Architektur bekannt.
Genau wie bei der Clean Architecture kann man diese Hexagonale Architektur in Schichten organisieren. Die äußerste Schicht besteht aus den Adaptern, die zwischen der Anwendung und den anderen Systemen übersetzen.
Als Nächstes kann man die Ports und die Use-Case-Implementierungen zur Anwendungsschicht (»application layer«) kombinieren, da sie die Schnittstelle Ihrer Anwendung definieren. Die letzte Schicht enthält die Domänen-Entities, die die Geschäftsregeln implementieren.
Die Geschäftslogik wird in den Use-Case-Klassen und -Entities implementiert. Die Use-Case-Klassen sind »schmale« Domänenservices, die jeweils nur einen einzigen Use Case implementieren. Man kann sich natürlich dafür entscheiden, mehrere Use Cases zu einem breiteren Domänenservice zu kombinieren, aber idealerweise macht man das nur, wenn die Use Cases häufig zusammen verwendet werden, um die Wartbarkeit zu verbessern.
Potenziell könnte man auch noch das Konzept der Anwendungsservices (»application services«) einführen. Ein Anwendungsservice ist ein Service, der Aufrufe an Use Cases (Domänenservice) koordiniert, wie die Abbildung zeigt.
Hier übersetzen die Anwendungsservices zwischen den Input- und den OutputPorts und den Domänenservices. Damit schirmen sie die Domänenservices vor der Außenwelt ab und koordinieren potenziell zwischen den Domänenservices. Die Domänenservice-Kästen sind synonym zu den Use-Case-Kästen aus der ersten Abbildung; hier kommt nur lediglich eine Terminologie zum Einsatz, die aus DDD entlehnt ist.
Wie diese Diskussion impliziert, steht es Ihnen frei, Ihren Anwendungscode innerhalb des Hexagons so zu entwerfen, wie es Ihnen passt. Sie können einfach oder raffiniert vorgehen, je nach der Komplexität und Größe Ihrer Anwendung.
Dieser Artikel ist ein Auszug aus dem Buch „Clean Architecture Praxisbuch“ von Tom Hombergs. Alle Infos zum Buch, das Inhaltsverzeichnis und eine kostenlose Leseprobe findet ihr bei uns im Shop.