Hexagonale Architektur: Robuste Software dank Schnittstellen statt Schichten

[00:00] Bevor wir in die hexagonale 

[00:03] möchte ich mit euch drei Fragen klären. Erstens, 

[00:11] was sind die Ziele einer Software Architektur? 

[00:16] beliebte Schichtenarchitektur im Hinblick 

[00:22] ersten Frage. Was ist Software Architektur? 

[00:28] Dienstleistung zur Verfügung stellen. 

[00:33] die benutzen einen Webbrowser und der greift über 

[00:40] haben wir verschiedene Komponenten, die zum einen 

[00:47] externen Komponenten wie einer Datenbank oder 

[00:53] Wir könnten auch eine App zur Verfügung stellen. 

[00:59] brauchen wir vielleicht eine weitere Komponente, 

[01:04] Architektur. Die Architektur, das ist also 

[01:11] die Anordnung und die Eigenschaften 

[01:16] wie diese Komponenten miteinander interagieren. 

[01:24] gute Antwort auf diese Frage hat Robert Martin 

[01:29] goal of a software architecture is to minimize the 

[01:36] required system." Und weiter: "If that effort is 

[01:42] system, the design is good." Wenn wir anfangen, 

[01:50] "Das Ziel einer Software Architektur ist es, den 

[01:55] gewünschten Systems zu minimieren." Das hört sich 

[02:01] hier meine Definition: "Eine gute Architektur 

[02:08] mit gleichbleibend geringem Aufwand zu ändern." 

[02:14] Kosten. Eure Arbeit- oder Auftraggeber:innen 

[02:20] langfristig planbaren Kosten ändern können. Und 

[02:27] Userwünschen, aber auch wenn die User gerade 

[02:32] nötig. Z. B. wenn Sicherheitslücken in einer 

[02:37] Komponente aktualisiert oder ausgetauscht werden 

[02:43] ändern. Ich war mal in einem Projekt, da haben 

[02:48] ich habe alle 6 Monate eine E-Mail von Facebook 

[02:53] bekommen. Oder auch wenn sich Gesetze ändern. 

[02:59] Software an die DSGVO anpassen. Das Ziel muss 

[03:05] Bob Martin auszudrücken: "To keep Software soft." 

[03:12] Komponenten aufteilen, die möglichst gekoppelt 

[03:17] getestet werden können. Ein gutes Beispiel ist das 

[03:23] die relativlose gekoppelt sind und die sich 

[03:29] voneinander mit gleichbleibend überschaubarem 

[03:36] Wie versuchen wir das in der Regel bei Software 

[03:42] kennen wir alle. Wir haben hier in der 

[03:46] Benutzerschnittstelle, die Anwendungsschicht mit 

[03:52] mit z. B. einer relationalen Datenbank und 

[03:58] Projekten bleibt es allerdings nicht lange bei 

[04:03] dass wir unter Zeitdruck ein Feature umsetzen 

[04:09] der Präsentationsschicht unter Umgehung der 

[04:14] auch einfach direkt auf Hibernate - oder aus der 

[04:20] erlaubt. Das nennt sich dann "offene" oder "nicht 

[04:26] unsere Anwendung irgendwann erweitern. Vielleicht 

[04:32] setzen wir eine Client Library in die Logikschicht 

[04:38] Logikschicht mit dem externen System. Aber dann 

[04:43] greifen - natürlich nur vorübergehend - aus der 

[04:50] Und eine App wollen wir auch noch unterstützen. 

[04:56] auf die Logikschicht zugreift. Aber dann sind da 

[05:02] in der Präsentationsschicht, die wir auch in der 

[05:08] da wieder dieses Feature, das schnellstmöglichst 

[05:13] noch einmal die Logikschicht. Und wenn wir 

[05:18] oder den Drittanbieter-Client, dann fällt das 

[05:23] unserer anfangs so sauberen Architektur nicht mehr 

[05:29] und alle bauen Code dort an, wo es ihnen gerade 

[05:36] Die Komponenten lassen sich nicht mehr isoliert 

[05:40] Tools wie Powermock. Powermock zu benutzen, das 

[05:47] Hauses mit Farbe überstreichen. Ihr versteckt 

[05:53] anstatt sie zu beheben. Und irgendwann stürzt das 

[05:59] Major-Version upgraden wollen und es Änderungen an 

[06:05] Schichten anpassen. In einem meiner letzten 

[06:11] verwendet und die konnten wir aus genau diesem 

[06:16] Schichten anpassen müssen, und das hätte Wochen 

[06:21] Update immer wieder herunterpriorisiert. Und 

[06:28] und wir konnten auch viele andere Libraries nicht 

[06:33] denen der alten EclipseLink-Version überschnitten 

[06:39] dann ist sie viel viel anfälliger für Bugs, und 

[06:46] die Höhe - und damit auch die Kosten. Das muss 

[06:53] dass die Schichtenarchitektur grundsätzlich 

[06:57] die erfolgreich damit umgesetzt wurden. Aber 

[07:02] anfangs saubere Schichtenarchitektur zu einer 

[07:08] wie eben dieser hier. Alister Cockburn hat 2005 

[07:15] vorgestellt, die genau diese Probleme 

[07:23] Aus diesem Blogartikel lassen sich drei Ziele 

[07:30] als Hexagon dargestellt - soll gleichermaßen von 

[07:37] automatisierten Tests gesteuert werden können. 

[07:43] sitzt, soll es keinen Unterschied machen, ob 

[07:48] einer REST-API oder einem Test-Famework 

[07:54] soll also von steuernden Komponenten, von 

[08:02] die Geschäftslogik im Anwendungskern soll isoliert 

[08:09] z. B. Mailversand und Drittanbieter-API entwickelt 

[08:15] Geschäftslogik soll es keinen Unterschied machen, 

[08:22] einer NoSQL-Datenbank oder serialisiert im File 

[08:29] also auch von gesteuerter Infrastruktur isoliert 

[08:37] sollen einfach austauschbar sein. Also z. B. eine 

[08:43] die Anpassung an geänderte externe Schnittstellen 

[08:50] Eine Modernisierung der Infrastruktur soll also 

[08:55] sein. Das ist ein bisschen so wie Autofahren. 

[09:02] ändern oder Verkehrsschilder austauschen, ohne 

[09:08] die Ziele. Wie kann die hexagonale Architektur 

[09:15] Dieses Hexagon stellt den Kern der Anwendung dar. 

[09:21] die Geschäftslogik der Anwendung. Hier gibt es 

[09:26] oder JPA-Repositories. Wir haben hier rein 

[09:34] Die Komponenten der Infrastruktur habe 

[09:37] denn wenn wir die Geschäftslogik entwickeln, 

[09:42] welche Infrastrukturkomponenten wir benötigen. Wie 

[09:49] Der Kern definiert Schnittstellen, die 

[09:55] schließen wir die sogenannten Adapter an, und die 

[10:00] Infrastruktur. Und jetzt kommt der entscheidende 

[10:07] Ports. Die Adapter und die Infrastruktur dahinter 

[10:14] vergleichen mit einem Mischpult. Es hat Eingänge, 

[10:21] eine E-Gitarre anschließen könnt, und es hat 

[10:28] oder ein Aufnahmegerät anschließen könnt. Aber 

[10:34] für das Mischpult keine Rolle. Und genau aus 

[10:42] An diese Ports könnt ihr jedes Gerät anschließen, 

[10:47] des Ports entspricht. Das war jetzt erstmal 

[10:53] nächstes ein ganz konkretes Beispiel. Wir beginnen 

[11:00] soll eine Benutzerregistrierung entgegennehmen. 

[11:06] Wie die Anwendung die Registrierung entgegennimmt, 

[11:11] oder eine REST-API ist für die Entwicklung der 

[11:18] Anwendung die Benutzerdaten irgendwo speichern. 

[11:24] und wie die Daten gespeichert werden, ist 

[11:29] noch eine Willkommensnachricht verschicken. Dafür 

[11:34] genau wir die Nachrichten verschicken, ob über 

[11:39] einen Unified-Messaging-Anbieter, auch das 

[11:45] An diese Ports können wir jetzt Adapter 

[11:51] wir eine Webseite implementieren, über die sich 

[11:56] anmelden können. Persistieren können wir 

[12:02] könnten wir einen JPA-Adapter z. B. mit Hibernate 

[12:09] benutzen wir unseren firmeninternen Mailserver, 

[12:16] Registrierung wollen wir neben der Webseite auch 

[12:22] unseren bestehenden Eingabeport einfach noch einen 

[12:28] auf den dann externe Anwendungen zugreifen 

[12:35] und Adaptern bei der Registrierung? Dazu werde 

[12:44] Nutzerin oder der Nutzer füllt im Browser ein 

[12:50] Browser schickt daraufhin die Formulardaten 

[12:56] Adapter wertet den POST-Request aus und ruft eine 

[13:03] könnte eine externe Anwendung die Nutzerdaten 

[13:10] Der wertet das JSON-Paket aus und ruft wieder die 

[13:16] Web-Adapter aufgerufen hat. Schauen wir einmal auf 

[13:24] Nutzerin oder den Nutzer zu speichern, ruft die 

[13:29] Persistance Port auf. Der JPA-Adapter generiert 

[13:37] an die Datenbank. Wie genau der JPA-Adapter das 

[13:43] einsetzt oder Hibernate oder EclipseLink - und 

[13:49] spielt aus Sicht des Anwendungskerns keine Rolle. 

[13:57] diese Isolierung funktioniert, zeige ich euch 

[14:02] sicher aufgefallen ist, gibt es zwei Arten 

[14:08] haben wir solche, die die Anwendung steuern, 

[14:13] die von der Anwendung gesteuert werden. Die 

[14:20] und Adapter und die gesteuerten bezeichnen wir 

[14:28] Durch die Ports und Adapter werden Anwendungskern 

[14:33] isoliert. Technische Details wie JPA, Hibernate, 

[14:41] nicht im Anwendungskern. Der Kern weiß nicht, 

[14:47] herum verwenden, und es spielt für ihn auch 

[14:52] vorhin und z. B. der E-Gitarre. Für das Mischpult 

[14:58] Gitarre gebaut ist, welche Saiten aufgezogen 

[15:05] ich heute schon sehr oft das Wort "Isolierung" 

[15:11] und das lässt sich auf Bildern auch schön 

[15:16] der Praxis? Wie lässt sich Isolierung in 

[15:23] Das möchte ich euch an einem Klassendiagramm 

[15:30] Darin haben wir die Implementierung der 

[15:35] Die öffentliche Schnittstelle dieses Services 

[15:40] `RegisterUserPort`, und der Service implementiert 

[15:48] ein REST-Controller zu, und der benutzt dann z. 

[15:54] Module aufteilen, z. B. zwei Maven-Module, dann 

[16:01] ein Controller-Modul. Das Controller-Modul hat 

[16:07] RESTEasy. Und da die Dependency von Controller 

[16:13] hat das Application-Modul auch keine Dependency 

[16:21] also nichts über die Technologie, die 

[16:27] Auf der anderen Seite haben wir unseren 

[16:31] Hibernate. Wie kann jetzt der Anwendungscode im 

[16:39] Wenn wir hier eine Dependency einrichten, dann 

[16:45] Dependency auf Hibernate - und damit nicht 

[16:50] Controller-Modul. Und genau diesen Rattenschwanz 

[16:56] Architektur vermeiden. Wir wollen zwar von hier 

[17:04] keine Dependency in diese Richtung und deshalb 

[17:11] sie, und zwar mit dem "Dependency Inversion 

[17:19] Wir setzen in das Application Hexagon 

[17:25] Der Service hat eine Abhängigkeit auf das 

[17:32] das Interface und wird per Dependency Injection 

[17:38] zwar der Aufruf von innen nach außen, aber die 

[17:46] damit hat der Anwendungskern keine Abhängigkeit 

[17:52] Abhängigkeit auf Hibernate. Der Kern hat also kein 

[17:58] kennt weder RESTEasy noch JPA oder Hibernate. All 

[18:06] außerhalb des Kerns in den Adaptern. Alle 

[18:13] zum Anwendungskern. Und das ist ein grundlegendes 

[18:19] auch einen Namen: Dependency Rule. Die Dependency 

[18:27] außen Richtung Anwendungskern gerichtet sein 

[18:34] ein Schutzschild für den Anwendungskern: 

[18:39] Einflüssen von außen ab. Hier seht ihr noch mal 

[18:47] zum Kern. Und das ermöglicht die Isolierung, die 

[18:54] es macht auch mehr Arbeit. Und damit kommen wir 

[19:02] dann sieht unsere User-Klasse in der Regel 

[19:08] und entsprechende Abhängigkeiten zu JPA. Wo 

[19:14] einmal auf das Klassendiagramm, und jetzt zoomen 

[19:22] User-Klasse hier in den Anwendungskern setzen, 

[19:28] Abhängigkeit vom Kern auf Hibernate. Die haben 

[19:34] Inversion entfernt und wir haben gelernt, dass 

[19:41] Prinzipien der hexagonalen Architektur, genau das 

[19:48] in das Adapter-Modul setzen, dann liegt zwar die 

[19:55] aber der `RegisterUserService` muss die 

[19:59] haben wir wieder die Dependency Rule verletzt. Um 

[20:05] Mapping-Strategien. Ich werde an dieser Stelle 

[20:10] Erfahrung nach in der Regel sinnvollste, und 

[20:16] Two-Way Mapping. Am Ende der Präsentation findet 

[20:22] einige andere Mapping-Strategien beschreibe. Beim 

[20:29] im Anwendungskern und eine im Adapter. Die heißt 

[20:36] Kern verwechselt zu werden. Die `JpaUser`-Klasse 

[20:42] die ich vorhin gezeigt habe. Die hat annotierte 

[20:48] noch Getter und Setter. Die User-Klasse im Kern 

[20:56] aber keine JPA-Annotationen. Dafür z. B. einen 

[21:02] dann ein neues gültiges User-Objekt erzeugt mit 

[21:08] dem Registrierungsdatum. Also alles rein fachliche 

[21:15] Domainmodell arbeiten, dann hat diese Klasse 

[21:20] User-Objekts ändern können. Wir haben also diese 

[21:27] JPA-Adapters, beim Aufruf der `saveUser()`-Methode 

[21:34] `JpaUser`-Objekt zu mappen und dieses dann über 

[21:41] natürlich auch noch eine `loadUser()`-Methode, 

[21:48] mappt dieses auf ein Anwendungs-User-Objekt und 

[21:52] Kern zurück. Als Code sieht das etwa so aus: Hier 

[22:02] ein `JpaUser`-Objekt und persistiert das dann 

[22:09] Und die load-Methode sieht so aus: Sie lädt das 

[22:17] und mappt das dann auf einem `User`-Objekt bzw. 

[22:24] ihr nicht selbst implementieren. Dafür gibt es 

[22:30] Wenn ihr googelt, findet ihr noch ein paar andere 

[22:35] einigen Jahren nicht weiterentwickelt. So ein 

[22:42] sondern auch beim REST-Adapter. Und dafür 

[22:49] Hier ist unsere `User`-Klasse - und oft wollen 

[22:53] REST-API sichtbar machen. Bei der `User`-Klasse 

[22:59] wollen oder die ID der Person, die diese Notiz 

[23:04] Zeitfelder definieren, wie diese in dem JSON-Paket 

[23:11] REST-Controller könnte z. B. so aussehen: Die 

[23:17] zu formatieren und hat dementsprechend eine 

[23:22] Und auch diese technische Abhängigkeit wollen 

[23:28] wieder das Klassendiagramm - also platzieren 

[23:36] außerhalb des Kerns in das Controller-Modul. 

[23:42] `registerUser()`-Methode das `UserDto`-Objekt 

[23:49] natürlich auch eine `getUser()`-Methode, 

[23:54] dem Anwendungskern auf ein `UserDto`. So 

[24:00] der hexagonalen Architektur sinnvoll - auch die 

[24:06] bei der hexagonalen Architektur ist es zwingend 

[24:11] aus dem Kern fernzuhalten und gleichzeitig 

[24:18] jetzt kommen wir zu einem der großen Vorteile 

[24:25] Am Anfang habe ich über die Ziele einer 

[24:29] habe ich als eine der Anforderungen isoliert 

[24:35] macht es die hexagonale Architektur sehr einfach, 

[24:44] können wir ganz einfach testen, indem wir ihn 

[24:49] die vom Test betroffenen sekundären Ports mit 

[24:55] in seiner Rolle als Spy die Aufrufe aus dem Kern 

[25:02] des Adapters simulieren. Der Test verifiziert 

[25:09] protokollierte Interaktion mit dem Adapter. Wir 

[25:14] den Adaptern testen, sondern auch andersherum die 

[25:22] der REST-Adapter. Testen können wir den z. B. mit 

[25:30] den Adapter, und der REST-Adapter ruft dann ein 

[25:36] Test Double soll wieder die Aufrufe protokollieren 

[25:43] Und der Adapter schickt dann eine Antwort zurück 

[25:49] verifiziert werden und die Interaktion mit dem 

[25:57] können wir von unserem Test aus mit Testcontainers 

[26:03] füllen. Dann ruft der Test den Adapter auf und 

[26:10] Datenbank schickt ihre Antwort an den JPA-Adapter, 

[26:17] können wir wieder die Antwort verifizieren und 

[26:22] Neben diesen Integrationstest sollten wir 

[26:27] auch immer End-to-End-Tests schreiben. 

[26:31] gesamte Anwendung werfen, dann können all diese 

[26:38] Genauso wie auch E-Gitarre, Keyboard, Mikrofon, 

[26:45] unabhängig voneinander getestet werden können. 

[26:51] Hexagon sehen - Alistair Cockburn wurde in einem 

[26:56] Hat das irgendeine besondere Bedeutung?" Und 

[27:02] Er wollte eine Form verwenden, die noch keiner 

[27:07] Fünfecke sind schwer zu zeichnen, also wurde es 

[27:13] wird, ist: "Was ist der Unterschied zwischen 

[27:19] Die Antwort ist ganz einfach. Es gibt keinen. 

[27:26] Der offizielle Name, den Alister Cockburn seiner 

[27:33] Die Bezeichnung "hexagonale Architektur" ergibt 

[27:38] viele Male gesehen habt. Alistair Cockburn hat in 

[27:43] dem ich euch nachher noch einen Link mitgebe, 

[27:48] also "hexagonale Architektur" vorzieht, aber 

[27:54] einer sein muss, der deren Eigenschaften 

[27:59] eben besser als "hexagonale Architektur". Und 

[28:05] die Ports-and-Adapters-Architektur von 

[28:11] Anwendungskern mit der Geschäftslogik und ohne 

[28:18] die im Code einfach Interfaes sind. Wir haben 

[28:24] und die wir an diese Ports anschließen. Primäre 

[28:31] implementieren sekundäre Ports. Wir haben die 

[28:39] und wir haben unseren Schutzschild, die Dependency 

[28:44] Richtung Kern zeigen müssen. Und jetzt möchte ich 

[28:50] in Erinnerung rufen und abgleichen, inwieweit die 

[28:57] sind noch mal die Ziele: Software soll leicht 

[29:01] gesamten Lebensdauer bleiben. Und das erreichen 

[29:07] strukturieren, die unabhängig entwickelbar 

[29:13] im Einzelnen durch. Änderbarkeit. Wir können die 

[29:21] ohne dass wir die Adapter oder die Infrastruktur 

[29:26] lassen. In der Praxis geht natürlich eine Änderung 

[29:32] User Interface und den Daten einher, sodass das 

[29:38] Viel wichtiger ist, dass wir die Adapter und auch 

[29:44] Jackson, Hibernate, aber auch die 

[29:48] z. B. die Datenbank aktualisieren oder komplett 

[29:55] Zeile Code in der Geschäftslogik ändern 

[30:00] auf die nächste Major Version upgraden wollen 

[30:06] dann ist davon ausschließlich der JPA-Adapter 

[30:11] die eine Abhängigkeit auf Hibernate hat. Um noch 

[30:17] Reifen wechseln wollt, dann braucht ihr vielleicht 

[30:22] kein neues Getriebe und keinen neuen Motor. Am 

[30:28] Artikelserie, in der ich demonstriere, dass selbst 

[30:33] technisches Detail der Infrastruktur sein kann. 

[30:40] ohne auch nur eine Zeile Code im Anwendungskern 

[30:46] Änderbarkeit einsortiere, ist der folgende: 

[30:51] Anwendungskerns beginnen und definiert erstmal nur 

[30:57] ohne dass ihr euch Gedanken über die Adapter 

[31:02] die ihr dahinter einsetzen wollt. Also ob 

[31:09] ob SQL oder NoSQL. Und so könnt ihr die 

[31:14] der Infrastruktur so lange hinauszögern, bis 

[31:21] viel Erfahrung über eure Anwendung gesammelt 

[31:26] welche Technologien am besten geeignet sind. 

[31:30] eure Daten am besten speichern lassen. Kommen 

[31:37] Eine lose Kopplung erreichen wir zum einen ganz 

[31:42] den Adaptern und zum anderen dadurch, dass wir die 

[31:49] wie hier z. B. Maven Module. Fachliche Themen 

[31:55] implementiert und alle technischen Themen in einem 

[32:01] zwischen den Modulen definieren wir entsprechend 

[32:07] dass keine technischen Abhängigkeiten in den Kern 

[32:12] eindeutig im Code lokalisieren können. Denn jetzt 

[32:19] überlegen, in welches Modul die Klasse gehört. 

[32:24] dann erreichen wir entweder von der neuen Klasse 

[32:30] oder wir erreichen die neue Klasse nicht von dem 

[32:37] "neuen Code mal eben irgendwo dran bauen", das ist 

[32:42] zahllosen transitiven Dependencies leider 

[32:49] unabhängige Entwicklung. Wenn der Anwendungskern 

[32:55] die weitere Arbeit an den Komponenten sehr gut 

[33:01] viertens, die unabhängige Testbarkeit. Das habe 

[33:06] können durch den Einsatz von Test Doubles alle 

[33:12] testen. Die hexagonale Architektur erfüllt damit 

[33:20] Solltet ihr also nur noch mit der hexagonalen 

[33:27] Architektur hat natürlich auch einen Nachteil. 

[33:33] Screenshot aus meiner IDE - aus einem Projekt 

[33:39] und außerdem noch einem separaten Modellmodul 

[33:46] Codes in Module, das Implementieren der Ports und 

[33:53] Mehraaufwand dar. Wenn ihr in jedem dieser 

[33:58] z. B. bei einem einfachen Microservice, der eine 

[34:03] ihr ausliest, dann lohnt sich dieser Mehraaufwand 

[34:09] wo jedes dieser Module nachher hunderte 

[34:13] Aufwand schnell amortisieren, und ihr könnt 

[34:20] wenn ihr eine Person im Team habt, die schon erste 

[34:24] hat und die abschätzen kann, ob sich dieser 

[34:30] besser: Entwickelt einfach mal selbst eine kleine 

[34:36] damit erste Erfahrung, und dann könnt ihr die 

[34:41] hexagonale Architektur ins Spiel bringt. Und damit 

[34:48] findet ihr die versprochenen Links und die Slides, 

[34:53] seid (seltener über Architektur, eher über 

[34:59] HappyCoders.eu vorbei oder bei einem der anderen