Stefan Zörner
07.11.2025
Sven Woltmann hält im Rahmen des Architektur-Punsches 2025 einen Vortrag zur hexagonalen Architektur. Stefan Zörner hat sich darüber mit ihm unterhalten.
(Stefan Zörner) “Sven, viele kennen dich von Java-Konferenzen, aber nicht alle. Wer bist du – und was machst du?”
Sven Woltmann: Ich bin in erster Linie Java-Programmierer – seit mittlerweile 30 Jahren, seit Java 1.0. Ich habe jede Java-Version miterlebt und alle Höhen und Tiefen, wobei ich sagen muss, dass es in den letzten Jahren eigentlich nur noch Höhen gibt.
2018 habe ich HappyCoders gegründet: Dort veröffentliche ich regelmäßig Artikel, vor allem zu neuen Java-Features, und ich biete Trainings an – aktuell etwa zur Modernisierung auf Java 25.
Man trifft mich auf vielen Java-Konferenzen und -Unkonferenzen, und demnächst natürlich beim Architektur-Punsch. Meistens spreche ich über die neuesten Java-Features, aber manchmal eben auch über hexagonale Architektur.
(StefanZ) “Du sagst: Architektur ist gar nicht dein Kerngebiet – wie bist du bei Hexagonaler Architektur gelandet?”
Sven: Durch die Praxis. In mehreren Projekten hat sich gezeigt: Wenn Software eine gewisse Größe und fachliche Komplexität erreicht, dann rechnet sich der architektonische Mehraufwand. Aus einem Kundenprojekt wurde eine Artikelserie – und daraus ein Vortrag. Ein bisschen „angeschubst“ hat mich übrigens Dein Kollege Falk: „Mach doch daraus mal einen Talk.“ So hat das Thema Fahrt aufgenommen.
(StefanZ) “Lass uns es kurz und knackig machen: Was ist hexagonale Architektur – in zwei, drei Sätzen?”
Sven: Bei der hexagonalen Architektur – auch „Ports & Adapters“ genannt – liegt die Geschäftslogik im Zentrum der Anwendung. Die Geschäftslogik definiert Schnittstellen, die sogenannten Ports, und an diese werden über Adapter die Komponenten der Infrastruktur angeschlossen, also User Interface, REST-Controller, Datenbank, ggf. andere Services.
Ports und Adapter führen zu einer Entkopplung, die zum einen die Fachlogik hervorragend testbar macht, und die es zum anderen erlaubt, Infrastrukturkomponenten zu aktualisieren oder auszutauschen, ohne dass die Geschäftslogik angepasst werden muss.
(StefanZ) “Viele verbinden „Schichtenarchitektur“ mit „sauber“. Worin liegt der Unterschied – und wo hakt es bei Layers?”
Sven: In klassischen Schichtenarchitekturen steht visuell oft die Datenbank „unten“ als Fundament, und die anderen Komponenten werden darüber „geschichtet“. In der Praxis entstehen dann gern Abkürzungen: Ein Controller greift direkt aufs ORM zu oder Fachlogik landet im Repository. Eine Änderung am ORM oder Datenbankschema kann dann die ganze Anwendung erschüttern. Hexagonal verhindert genau solche Kurzschlüsse: Die Geschäftslogik im Kern „kennt“ nur ihre Ports; Adapter kapseln alles andere.
(StefanZ) “Passt Domain-Driven Design (DDD) dazu – oder ist das Konkurrenz?”
Sven: DDD und Hexagonal ergänzen sich hervorragend. DDD liefert die Sprache, die Modelle und die Bounded Contexts; Hexagonal ist ein sehr passendes Umsetzungsmuster, um diese Domäne technisch zu schützen. Man entwickelt erst das Domänenmodell und implementiert es dann so, dass es nicht von Technikdetails vereinnahmt wird. Anders gesagt: DDD beantwortet das „Was“ und „Warum“, Hexagonal das „Wie“ der technischen Kapselung.
Ein einzelner Service kann sehr gut hexagonal aufgebaut sein.
(StefanZ) “Und wie steht’s mit Microservices: Gegensatz oder Ergänzung?”
Sven: Ergänzung – aber in der richtigen Granularität. Ein einzelner Service kann sehr gut hexagonal aufgebaut sein. Für winzige „Nano-Services“ lohnt der Overhead aber selten. Spannend wird es bei größeren, fachlich gehaltvollen Services oder Self-Contained Systems. Die Services sprechen über klar definierte Ports; Adapter verbinden sie mit anderen Services. Die Domäne selbst weiß nichts von HTTP-Clients oder Message-Queues – sie formuliert nur Use Cases.
(StefanZ) “Wann würdest du zur hexagonalen Architektur raten – und wann eher nicht?”
Sven: Besonders gut passt die hexagonale Architektur bei größeren Anwendungen mit komplexer Geschäftslogik, die auf Langlebigkeit ausgelegt sind. „Größer“ deshalb, weil der Ansatz natürlich einen gewissen Overhead mitbringt – etwa durch die Einführung von Ports und Adaptern oder das notwendige Mapping zwischen Domänen- und Infrastrukturmodellen. Das lohnt sich, wenn die Anwendung fachlich anspruchsvoll ist und über Jahre weiterentwickelt werden soll.
Bei kleinen Microservices, die im Wesentlichen nur ein paar Entities in eine Datenbank schreiben und wieder auslesen, zahlt sich dieser Aufwand nicht aus. Dort gibt es nur minimale Geschäftslogik … und dafür brauchen wir dann keine Architektur, die die Geschäftslogik ins Zentrum stellt.
Auch bei Proof-of-Concepts oder kurzlebigen Projekten ist der Mehraufwand unverhältnismäßig hoch.
(StefanZ) “Für wen hältst du deinen Vortrag beim Architektur-Punsch – wen möchtest du im Publikum?”
Sven: Alle, die robuste, langfristig wartbare Software bauen wollen. Die Session ist eine Einführung: Wer Hexagonal noch nie gehört hat, bekommt ein klares Bild davon, versteht Vorteile und Trade-offs – und kann vielleicht beim nächsten Projekt die hexagonale Architektur in Betracht ziehen.
(StefanZ) “Braucht man dafür bestimmte Technologien – oder gar eine spezifische Sprache?”
Sven: Es sollte eine moderne Sprache mit Interfaces und Implementierungen sein: Java, C#, Go – wichtig ist die Möglichkeit, klare Modulgrenzen ziehen zu können. Hilfreich sind Modul- oder Build-Modul-Schnitte (z. B. Maven-Module), damit Zugriff wirklich nur über die definierten Schnittstellen, eben die Ports, erfolgt. In Sprachen ohne diese Mechanismen funktioniert es auch, aber man ersetzt Compiler-Unterstützung durch Konvention und Disziplin – und das funktioniert ja auch bei der Schichtenarchitektur nicht gut.
(StefanZ) “Hast Du mal ins Punsch-Programm geschaut? Was schaust du dir selbst an?”
Sven: Sehr gern „Software-Architektur für KI-Systeme“ von Felix Kammerlander – weil viele KI-Vorträge bisher theoretisch bleiben. Hier erhoffe ich mir praktische Einblicke; der Slot ist ja als Doppelformat mit Workshop geplant. Parallel dazu läuft der Talk „Der modulare Monolith“ von Falk – als spannender Gegenentwurf in der Architektur-Debatte. Schweren Herzens werde ich wählen müssen.
(StefanZ) “Hast Du eine besondere Erfahrung in Deinem Berufsleben gemacht, nach der ich Dich aber niemals fragen würde?”
Sven: Weihnachten 1998 habe ich in Seattle zusammen mit Jeff Bezos Bücher gepackt. Ich war damals über eine Akquisition einige Monate bei Amazon – und an den Peak-Tagen mussten wirklich alle ins Lager. Man lief zwischen 20, 30 Leuten, zog Bücher aus den Regalen, packte Kisten – Bezos mittendrin.
(StefanZ) “Das ist eine großartige Geschichte – und ein schöner Schluss. Danke dir, Sven – wir sehen uns beim Architektur-Punsch!”
Sven: Ich freue mich drauf. Bis zum 8. 12.!
Ein geselliger Vorweihnachtsnachmittag mit tollen Menschen, spannenden Vorträgen und vielen interaktiven Formaten.
Der Vortrag von Sven ist Teil unseres Architektur-Punsches 2025 am 08. Dezember. Natürlich gibt es da noch weitere spannende Programmpunkte zu entdecken. Einfach anmelden! Details findet ihr hier …