Was ist die hexagonale Architektur und warum sollte man sie implementieren?
Die Wahl der Architektur Ihrer Web- oder mobilen Anwendung erfolgt in der Regel zu Beginn eines Projekts, während der Phase der technischen Konzeption. Dieses Element beeinflusst die Art und Weise, wie Sie die wiederkehrenden Designprobleme Ihrer Anwendung, der Geschäftsrepräsentation, der Einheitentestbarkeit und Integration lösen werden. Diese Architektur ist auch entscheidend für die Langlebigkeit der Anwendung, die Sie entwickeln. Für eine Agentur, die Geschäftsanwendungen oder mobile Anwendungen erstellt, ist es die Aufgabe des Lead Développeur, diese Architektur zu definieren.
Es gibt mehrere Architekturmuster oder Design Patterns. Die strategischen Patterns, die aufzeigen, wie Sie Ihre Anwendung aufbauen können (ihre Verwendung wird für die Identifizierung von Geschäftskontexten empfohlen), und die taktischen Patterns, die es ermöglichen, das Produkt korrekt zu erstellen. Die hexagonale Architektur, Gegenstand dieses Artikels, gehört zu dieser zweiten Kategorie, ebenso wie das Domain Driven Design (DDD).
Die hexagonale Architektur, ein geschäftsorientiertes Anwendungsdesignmodell
Der Ursprung der hexagonalen Architektur
Alistair Cockburn, Mitunterzeichner des Agilen Manifests im Jahr 2001, ist der Ursprung der hexagonalen Architektur. Das Ziel dieses 2005 erstellten Architekturmusters ist es, Probleme zu vermeiden, die bei MVC-Architekturen (Model-View-Controller) auftreten, bei denen es zu einer Vermischung von Schichten kommt (Abhängigkeit von View und Model, Controller und View, Model und Controller), was die Durchführung von Unit-Tests und die Codewartung erschwert. Dies wirkt sich auch auf die Performance der Anwendung aus.
Diese Art von Modell erschwert Änderungen an der Geschäftslogik, mit potenziellen Regressionen und schädlichen Nebeneffekten für die Integrität der Anwendung.
Die hexagonale Architektur entspricht dem Konzept der Clean Architecture. Diese zielt darauf ab, die Abhängigkeiten der Geschäftslogik von der technischen Infrastruktur zu reduzieren, um die Stabilität der Anwendung während ihres gesamten Lebenszyklus (Update- und Testphase) aufrechtzuerhalten, aber auch bei technischen Entwicklungen der Infrastruktur.
Die Grundprinzipien der hexagonalen Architektur
Das Prinzip der hexagonalen Architektur basiert auf:
Die explizite Trennung der drei Schichten, aus denen die Architektur besteht. Im Zentrum des Hexagons ist die Business Logic (Geschäftslogik) der Kern des Reaktors. Ausserhalb des Hexagons befindet sich die Infrastruktur. Sie besteht aus der User-Side, die alle Elemente gruppiert, die die Domäne abfragen (Benutzerkonsole, Controller, REST-Schichten, Event Streaming, Batch Launcher usw.), und der Server-Side, die allen Elementen (Informationen/Diensten) entspricht, die die Anwendung zum Funktionieren benötigt (Datenbank, Dateisystem, Web Services…).
Die Abhängigkeiten, die ausschliesslich von aussen, von den User-Side- und Server-Side-Komponenten, zur Domäne führen.
Die Interaktionen zwischen den Infrastruktur- und Geschäftsbereichen, die über Ports und Adapters API (Application Programming Interface) und SPI (Service Provider Interface) verwaltet werden.
Die API und SPI befinden sich innerhalb des Hexagons und manipulieren nur die Geschäftsobjekte der Domäne. Die API stellen die Schnittstellen zur Abfrage der Domäne bereit, und die SPI bündeln die für die Domäne notwendigen Schnittstellen, um Daten von Drittmodulen abzurufen. Diese Schnittstellen werden innerhalb des Hexagons genutzt und von den Infrastrukturelementen der Server-Side implementiert.
Die hexagonale Architektur wird auch Ports & Adapters Architecture genannt. Die Kommunikationsports der Domäne sind die API und SPI, und die Adapter sind die Infrastrukturmodule, die sie implementieren und nutzen.
Das Prinzip dieser Architektur besteht also darin, die Geschäftslogik, die sich innerhalb des Hexagons befindet, von den technischen Prozessen, die sich ausserhalb befinden, zu isolieren, wobei das Hexagon eine Grenze zwischen dem technischen Code und dem Geschäftscode darstellt. Es gibt keine Abhängigkeit zwischen diesen beiden Welten. Die Geschäftsdomäne ist streng unabhängig von technischen Elementen wie der Verwaltung von Kommunikationsprotokollen, Flows, der Präsentation (Benutzeroberflächenlogik) usw. Dazu wird im Vorfeld Designarbeit geleistet, um alles zu identifizieren, was die Geschäftslogik ausmacht, und diese Elemente innerhalb des Hexagons zu positionieren.
Die Vorteile der Verwendung einer hexagonalen Architektur
Unabhängigkeit der Geschäfts- und technischen Infrastrukturschichten
Der Hauptvorteil der hexagonalen Architektur ist die Gewährleistung der Unabhängigkeit der Geschäftslogik, die sich innerhalb des Hexagons befindet, von der ausserhalb positionierten Infrastruktur. Durch die Isolierung des Geschäftscodes vom Rest der Anwendung gewährleistet diese Architektur die Wiederverwendbarkeit der Geschäftsrepräsentation.
100% Testbarkeit der Geschäftsdomäne
Ein weiterer Vorteil der hexagonalen Architektur ist ihre Testbarkeit. Da alle technischen Probleme der Infrastruktur und Integration unabhängig behandelt werden, interagieren die funktionalen Tests direkt mit der Geschäftsdomäne, ohne Störung durch andere Schichten.
Die Testbarkeit der Geschäftsdomäne wird somit erhöht, mit einer Abdeckung von 100% durch Unit-Tests. Integrationstests, die Infrastrukturaspekte betreffen, sind etwas langsamer, aber durch ihre Isolation bewahren sie die Integrität der Geschäftsdomäne.
Modularität und Skalierbarkeit
Da die hexagonale Architektur entkoppelt ist, kann sie eine grosse Vielfalt von Adapters integrieren. Diese starke Modularität ermöglicht es, verschiedene Schichten gleichzeitig zu betreiben, ohne die Geschäftsdomäne zu beeinträchtigen.
Technische und funktionale Erweiterbarkeit
Dank dieser entkoppelten Architektur werden technische und funktionale Weiterentwicklungen erleichtert. Zum Beispiel wird auf der SPI-Seite bei der Migration einer SQL-Datenbank zu einer NoSQL-Datenbank der Rest der Anwendung nicht beeinträchtigt und die Langlebigkeit des Geschäftscodes nicht in Frage gestellt. Auf die gleiche Weise kann dieser in einer anderen hexagonalen Architektur implementiert werden und mit einer anderen Infrastruktur funktionieren.
Ein Geschäftsansatz im Einklang mit den Kundenerwartungen
Die Geschäftsschicht ist das zentrale Element des Systems. Zu Beginn können sich die Projektteams auf das Design der Geschäftslogik und die erwarteten Funktionalitäten konzentrieren. Sie haben somit ein perfektes Verständnis der Kundenbedürfnisse und können die technischen Entscheidungen später verschieben, damit sie optimal zu den Projektanforderungen passen.
Designmethode
Um die Verwendung einer hexagonalen Architektur zu optimieren, muss das Projekt im Inneren des Hexagons, der Geschäftsschicht, begonnen werden. Dies ist der Mehrwert der Anwendung für den Kunden und das Element, das die Entscheidungen leiten sollte, mehr als die reine Technik. Der Projektstart ist somit schneller, da die Infrastrukturaspekte erst im zweiten Schritt erfolgen und es dann möglich ist, die Geschäftsfunktionalitäten schneller zu liefern.
Anschliessend sollte man sich auf die Funktionalitäten und nicht auf technische Details konzentrieren und die technische Umsetzung kurz vor Beginn der Entwicklungsphase entscheiden. In der Regel ist es schwierig, zu Beginn eines Projekts die am besten geeignete technische Implementierung zur Erfüllung der Anforderungen zu bestimmen. Die Entkopplung der Geschäftslogik von der technischen Infrastruktur ist die Garantie für die Qualität der Geschäftsdomäne, ihre Langlebigkeit und ihre Robustheit gegenüber kontinuierlichen technischen Entwicklungen.
