Vielleicht kommt Ihnen das bekannt vor: Sie starten ein neues Projekt – voller Motivation und mit dem guten Gefühl, alles von Anfang an sauber umzusetzen. Also wählen Sie die klassische Architektur, die man überall kennt: oben die Nutzeroberfläche, unten die Datenbank, dazwischen ein wenig API. Das sieht ordentlich aus, fühlt sich professionell an, und man denkt sich: So baut man gute Software. Schließlich steht es ja so auch in den Lehrbüchern und in sämtlichen Framework-Tutorials. Und am Anfang funktioniert das auch wunderbar. Die ersten Funktionen entstehen fast von selbst. Sie klicken sich durch die Oberfläche, speichern Daten in der Datenbank, und alles wirkt kontrollierbar und aufgeräumt. Jede Schicht scheint genau das zu tun, wofür sie gedacht ist.

Und dann vergehen ein paar Monate – und die ersten Probleme beginnen sich langsam zu zeigen. Plötzlich benötigen Sie die Datenbank, um Ihre Tests überhaupt starten zu können. Ein kleines neues Feature zwingt Sie dazu, Änderungen an drei oder vier Stellen gleichzeitig vorzunehmen. Und irgendwie ist Ihre Geschäftslogik in die Controller gerutscht oder steckt direkt in der Datenbank. Fachlichkeit und Technik beginnen, sich immer stärker zu vermischen.

Dann kommt irgendwann der Tag, an dem Sie etwas Größeres anfassen müssen. Vielleicht müssen Sie das Framework aktualisieren, weil das alte nicht mehr unterstützt wird. Vielleicht möchten Sie die Datenbank austauschen oder eine völlig neue Nutzeroberfläche aufsetzen. Und genau in diesem Moment merken Sie, dass Sie gefangen sind, gefangen in Ihrer eigenen Architektur. Was am Anfang noch so ordentlich aussah, entpuppt sich in Wirklichkeit als Falle.

Das Problem mit klassischen Architekturen

Wenn wir uns einmal etwas genauer anschauen, warum klassische Architekturen langfristig häufig so viele Probleme verursachen, dann ist das zunächst gar nicht offensichtlich. Auf dem Papier wirken sie nämlich sauber. Wir haben unsere Schichten: ganz oben die Nutzeroberfläche, in der Mitte die API oder vielleicht ein paar Services, und ganz unten die Datenbank. Alle wissen, wo ihr Code jeweils hingehört, und anfangs entsteht das gute Gefühl, dass man eine saubere, gut strukturierte Anwendung entwickelt.

Doch sobald die Software wächst, zeigt sich die Realität. Fachlichkeit und Technik lassen sich in der Praxis fast nie sauber trennen. Ein neues Feature kommt, und plötzlich verteilt sich die Geschäftslogik: Ein Teil landet im Controller, ein anderer Teil in den Datenbank-Entities und ein weiterer Teil in irgendeinem Service. Denn natürlich ist es bequem, von irgendwo schnell einmal auf ein Framework-Feature zuzugreifen oder direkt eine Datenbank-Annotation zu verwenden, statt eine saubere Schnittstelle zu definieren. Und mit jedem dieser kleinen Schritte wird Ihre Software ein Stück enger mit der Technik verflochten.

Am Anfang merken Sie das kaum. Doch nach ein paar Monaten wird es plötzlich unmöglich, Ihre Geschäftslogik ohne die Datenbank oder das Framework zu starten. Wenn Sie testen möchten, benötigen Sie zunächst eine laufende Datenbank. Wenn Sie refaktorisieren wollen, müssen Sie darauf achten, keine versteckte Magie des Frameworks unbeabsichtigt zu beschädigen.

Fachlichkeit und Technik vermischen sich

Das führt dazu, dass Ihre Software zunehmend unbeweglich wird. Jede Änderung wird riskant. Ein simples neues Feature zieht sich durch mehrere Schichten, und selbst kleinste Anpassungen können Nebenwirkungen haben, die Sie erst bemerken, wenn etwas ganz anderes nicht mehr funktioniert. Und je länger das Projekt läuft, desto größer wird die Unsicherheit vor Änderungen. Notwendige Refactorings werden häufiger verschoben. Irgendwann kommt dann der Moment, an dem Sie etwas wirklich Grundlegendes ändern müssen. Vielleicht benötigen Sie ein Framework-Upgrade, weil Sicherheitslücken bekannt geworden sind. Vielleicht müssen Sie die Datenbank wechseln, weil Ihr Produkt skalieren soll. Oder Sie möchten eine neue Nutzeroberfläche entwickeln, weil Ihre Anwendung auf einer anderen Plattform laufen soll.

Und genau in diesem Moment stellen Sie fest, dass Sie in Ihrer Architektur gefangen sind. Die Geschäftslogik ist inzwischen so eng mit der Technik verknüpft, dass sie kaum noch zu entkoppeln ist. Genau das ist die große, unsichtbare Falle der klassischen Drei-Schichten-Architektur. Sie vermittelt anfänglich ein Gefühl von Ordnung – doch je größer Ihr System wird, desto höher fällt der Preis für diese scheinbare Ordnung aus. Es fehlen allzu oft klare Grenzen zwischen dem, was fachlicher Kern ist, und dem, was lediglich technische Infrastruktur sein sollte. Und ebendiese fehlenden Grenzen machen Ihre Software langfristig teuer, unflexibel und fehleranfällig.

Wenn diese strukturelle Falle erst einmal erkannt ist, stellt sich unmittelbar die Frage: Wie kann man ihr entkommen? Die Antwort darauf ist überraschend einfach – und gleichzeitig radikal. Die Geschäftslogik muss so gestaltet werden, dass sie vollständig unabhängig von Datenbanken, Frameworks und Benutzeroberflächen funktioniert. Genau das ist die Grundidee der hexagonalen Architektur.

Was ist hexagonale Architektur?

Hexagonal bedeutet in diesem Zusammenhang nicht, dass künftig alle Komponenten in Form von Sechsecken dargestellt werden müssten. Es geht vielmehr darum, dass Ihre Anwendung einen stabilen Kern erhält, und alles, was sich außen herum befindet, austauschbar wird. Dieser Kern ist die sogenannte Domain – also die Geschäftslogik, die das eigentliche Kerngeschäft abbildet. Alles andere – sei es Benutzeroberfläche, Datenbank, API, Messaging-System oder Cloud-Service – ist lediglich ein Adapter, also gewissermaßen ein Plug-in, das sich an diesen Kern andockt.

Um das Bild greifbar zu machen: Stellen Sie sich Ihre Anwendung als Insel vor. Im Zentrum dieser Insel befindet sich Ihre Geschäftslogik. Das ist jener Teil, der Ihr Produkt ausmacht, der Ihr Unternehmen besonders macht und für den Kundinnen und Kunden letztlich bezahlen, weil hier die eigentliche Wertschöpfung erfolgt. Außen herumliegt das Wasser, und auf der gegenüberliegenden Seite liegt die große weite Welt: Benutzeroberflächen, Datenbanken, externe Systeme, Frameworks und mehr. Um diese Welt nun mit Ihrer Geschäftslogik zu verbinden, bauen Sie Brücken – genau diese sind die Adapter. Wenn Sie dann eine dieser Brücken austauschen, bleibt die Insel selbst davon völlig unberührt.

Viele Teams betonen zwar, dass sie Domain-Driven Design (DDD) anwenden – tatsächlich enthalten die Objekte jedoch häufig nur Daten, während sämtliche Entscheidungen in Services ausgelagert werden. Eine echte hexagonale Architektur entfaltet ihre Stärken jedoch erst dann, wenn die Domain tatsächlich Verhalten enthält: also Regeln, Invarianten und Entscheidungen. Wenn die Objekte hingegen keine eigene Logik mitbringen, entsteht erneut Spaghetti-Code. Auch das schönste Hexagon kann daran nichts ändern. Solche Datenmodelle, die keine eigene Logik tragen, werden deshalb auch als anämisch – also gewissermaßen blutarm – bezeichnet.

Onion Architecture, Clean Architecture & Co.

Vielleicht sind Ihnen in diesem Zusammenhang auch schon die Begriffe „Onion Architecture“ oder „Clean Architecture“ begegnet. Im Kern handelt es sich dabei jeweils um denselben Ansatz wie bei hexagonaler Architektur. Alle drei Architekturmodelle verfolgen nämlich das gleiche Ziel: Die Geschäftslogik soll ins Zentrum rücken, die Technik nach außen treten. Unterschiede bestehen hauptsächlich in der Darstellung und in einzelnen Details. Die Onion Architecture verwendet das Bild konzentrischer Ringe, die Clean Architecture ergänzt Begriffe wie Entities, Use Cases und Interfaces, und die hexagonale Architektur spricht stattdessen von Ports und Adaptern – häufig in der Darstellung eines Sechsecks. In der praktischen Umsetzung sind diese Begriffe jedoch vor allem unterschiedliche Perspektiven auf eine gemeinsame Grundidee. Wer das Prinzip der hexagonalen Architektur verstanden hat, besitzt damit zugleich das Fundament für Onion und Clean Architecture.

Häufig wird moderne Architektur auch unmittelbar mit Microservices in Verbindung gebracht – jedoch bedeutet die Verwendung hexagonaler Architektur nicht automatisch, dass Microservices eingesetzt werden müssen. Auch ein modularer Monolith – gelegentlich auch als „Modulith“ bezeichnet – kann problemlos auf Basis einer hexagonalen Struktur aufgebaut werden. Und wenn später ein Wechsel hin zu Microservices ansteht, gelingt dieser deutlich einfacher, weil durch die fachlichen Grenzen bereits alle strukturellen Voraussetzungen erfüllt sind. Microservices bieten jedoch den Vorteil, dass sie diese Struktur oft noch konsequenter erzwingen. Meiner persönlichen praktischen Erfahrung nach funktioniert der fachliche Ansatz daher in Verbindung mit Microservices häufig besonders gut.

Abhängigkeiten von außen nach innen

Der zentrale Mechanismus der hexagonalen Architektur besteht – wie bereits erwähnt – aus Ports und Adaptern. Ein Port ist dabei eine Schnittstelle, die Ihre Geschäftslogik entweder anbietet oder von außen erwartet. Ihr Fachmodell könnte etwa formulieren:

„Um ein Buch auszuleihen, benötige ich ein Repository, das mir Bücher liefert und Speichervorgänge entgegennimmt.“

Es legt aber nicht fest, wie dieses Repository konkret implementiert ist. Es definiert lediglich den Vertrag – genau das ist der Port. Der Adapter, also die Brücke in unserem Bild, ist die konkrete Umsetzung. Er weiß, wie er diese Schnittstelle erfüllt: Vielleicht verwendet er eine PostgreSQL-Datenbank, vielleicht eine EventSourcingDB, vielleicht ein einfaches In-Memory-Array für Tests – oder etwas ganz anderes. Für Ihre Geschäftslogik spielt das keine Rolle. Sie kennt ausschließlich die Schnittstelle, nicht aber die dahinterliegende technische Umsetzung.

Entscheidend dabei ist die Richtung der Abhängigkeiten. In einer klassischen Schichtenarchitektur hängt der Fachcode fast immer von der Technik ab: Die Nutzeroberfläche ruft Services auf, Services greifen auf Repositories zu, und diese sind direkt mit der Datenbank verbunden. In der hexagonalen Architektur hingegen ist es genau umgekehrt: Die Technik hängt an der Geschäftslogik, aber die Geschäftslogik weiß nichts von der Technik. Dadurch erzielen Sie drei wesentliche Vorteile:

• Erstens wird Ihre Software testbar, weil Sie die Geschäftslogik isoliert prüfen können.
• Zweitens wird sie anpassbar, weil Sie Datenbanken, Benutzeroberflächen und Frameworks austauschen können, ohne die Geschäftslogik ändern zu müssen.
• Und drittens wird sie langlebig, weil der fachliche Kern Ihrer Software vollständig unabhängig bleibt von Technologien, die in wenigen Jahren bereits veraltet sein könnten.

Damit die Geschäftslogik auch tatsächlich unabhängig bleibt, werden die Adapter – wie beschrieben – von außen bereitgestellt. Dies erfolgt typischerweise über Dependency Injection. Die Domain kennt somit nur die Ports – wer die jeweilige Implementierung liefert, entscheidet die Außenwelt zur Laufzeit. Das ist kein exklusives Merkmal der hexagonalen Architektur, sondern schlicht saubere Entkopplung.

„Wir sind aber nicht Netflix!“

Vielfach wird angenommen, dass eine so strukturierte Architektur nur bei besonders großen Systemen erforderlich sei. Häufig fällt dann der Satz:

„Wir sind aber nicht Netflix!“

Das jedoch greift zu kurz. Natürlich handelt es sich bei den meisten Systemen nicht um Plattformen dieser Größenordnung. Dennoch gilt: Jede Software, die überhaupt einen Zweck erfüllt, enthält auch Fachlichkeit – also auch Ihre Software. Denn niemand entwickelt Software ausschließlich aus technischer Neugier, sondern fast immer, weil ein fachliches Problem gelöst werden soll. Und genau deshalb gehört die Fachlichkeit immer in den Mittelpunkt. Möglicherweise benötigen Sie nicht in jedem Projekt CQRS oder Event Sourcing. Aber ein klares Verständnis davon, welche fachlichen Begriffe und Regeln Ihre Software prägen, benötigen Sie immer. Wenn Sie diese Fachlichkeit konsequent ins Zentrum stellen, ergibt sich die Technik darum herum nahezu von selbst. Genau darum geht es.

Wenn Sie Ihre Software also so gestalten, dass die Geschäftslogik im Zentrum steht und die Technik nur außen angedockt ist, verändert sich die Arbeit damit grundlegend. Denn plötzlich fühlt sich Softwareentwicklung wieder leicht an – selbst in sehr großen Projekten. Der erste große Vorteil ist die Testbarkeit. Sie können Ihre Geschäftslogik vollständig isoliert prüfen – ohne laufende Datenbank, ohne gestartetes Framework, ohne Abhängigkeit von der Außenwelt. Sie schreiben einen Test, instanziieren die Geschäftslogik, geben ihr die benötigten Daten – und prüfen, ob sie das richtige Verhalten zeigt. Das spart Zeit und schafft vor allem Sicherheit: Sie wissen, dass Ihr Kerngeschäft funktioniert – unabhängig davon, was außerhalb geschieht.

Der zweite Vorteil ist die Flexibilität. Wenn Ihre Geschäftslogik keine Kenntnis von Datenbanken, Frameworks oder technischen Details hat, können Sie diese jederzeit austauschen. Heute arbeiten Sie vielleicht mit PostgreSQL, morgen mit einer EventSourcingDB oder MongoDB. Sie könnten Ihre Nutzeroberfläche von einer klassischen Webanwendung auf eine mobile App oder eine reine API-Variante umstellen. Ihre Geschäftslogik bleibt unverändert – ein enormer Vorteil für die langfristige Wartbarkeit.

Der dritte Vorteil ist die Langlebigkeit Ihrer Software. Technologien kommen und gehen. Frameworks und Werkzeuge werden abgelöst. Die Geschäftslogik jedoch bleibt in vielen Fällen über Jahre im Einsatz. Wenn sie von Anfang an unabhängig gehalten wird, schützen Sie damit den wertvollsten Teil Ihrer Software: das eigentliche Kerngeschäft. Refactorings verlieren ihren Schrecken, weil klar ist: Die Technik ist austauschbar – aber die Logik bleibt stabil. Viele Teams erkennen diese Falle erst spät und müssen dann aufwendig umbauen. Wer früh mit hexagonaler Architektur beginnt, erspart sich diesen Schritt. Doch auch ein späterer, schrittweiser Umbau ist möglich: Zunächst die Grenzen ziehen, dann Adapter definieren, anschließend die Technik entkoppeln. Architektur ist in den meisten Fällen ein evolutiver Prozess – kein Big Bang.

Zugang zu modernen Architekturmustern

Hexagonale Architektur ist übrigens nicht nur für sich genommen interessant – sie eröffnet auch den Zugang zu modernen Architekturmustern wie Event Sourcing und CQRS. Vielleicht haben Sie bereits von CQRS gehört – falls nicht: Es lohnt sich, sich damit einmal näher zu beschäftigen. Das Akronym CQRS steht dabei für Command Query Responsibility Segregation und bedeutet, dass Lese- und Schreiboperationen in der Anwendung konsequent getrennt werden: Commands verändern den Zustand, Queries lesen ihn aus. Event Sourcing geht sogar noch einen Schritt weiter: Anstelle des aktuellen Zustands werden sämtliche Änderungen, die im Laufe der Zeit stattfinden, als Events gespeichert. So entsteht ein wertvoller Datenschatz, der sich analysieren, auswerten und zur Verbesserung der Fachlichkeit nutzen lässt. Und als zusätzlicher Vorteil: Sie schreiben Ihre Geschäftslogik mit konsequentem Fokus auf die Fachlichkeit – nicht auf die Technik. Als Einstieg in die Thematik sei die Website cqrs.com empfohlen.

Gerade hier zeigt sich übrigens sehr gut, wie perfekt die hexagonale Architektur ins Gesamtbild passt: Commands und Queries sind in dieser Architektur nämlich einfach Ports – also Schnittstellen, über die die Geschäftslogik angesprochen wird. Ob ein Command nun über eine HTTP-API, eine Message-Queue oder einen Testfall hereinkommt, spielt für die Geschäftslogik keine Rolle. Auch die Anbindung des Event-Stores ist lediglich ein Adapter, der die Ports bedient. Das bedeutet: Wenn Sie später auf CQRS oder Event Sourcing umsteigen möchten, müssen Sie nicht bei null beginnen. Ihre Anwendung ist bereits vorbereitet – durch die klare Trennung von Fachlogik und Technik.

In einer zunehmend verteilten Welt, in der Themen wie Streaming, Real-Time-Processing und Cloud-native-Architekturen an Bedeutung gewinnen, ist das ein erheblicher Vorteil. Sie bauen heute eine robuste, langlebige Anwendung – und halten sich zugleich die Tür für zukünftige Technologien offen.

Heute schon an morgen denken

Klassische Architekturen wirken zu Beginn sehr sauber, entwickeln sich jedoch im Laufe der Zeit zur Falle. Fachlogik und Technik vermischen sich, Änderungen werden riskant, und plötzlich hängt Ihre gesamte Anwendung an Frameworks und Datenbanken, die eigentlich nur Hilfsmittel sein sollten. Die hexagonale Architektur kehrt dieses Verhältnis um. Sie stellt die Fachlogik in den Mittelpunkt und macht die Technik austauschbar.

Das Ergebnis: testbare, flexible und langlebige Software. Sie schaffen sich die Freiheit, auf neue Anforderungen und Technologien zu reagieren, ohne das Kerngeschäft Ihrer Anwendung ständig neu aufbauen zu müssen. Wer Software auf diese Weise gestaltet, schützt damit das Wertvollste, was ein Team besitzt: das eigene Fachwissen. Denn alles andere ist nur Infrastruktur – und diese kann jederzeit ersetzt werden.

(rme)