Hexagonale Architektur ist ein mächtiges Werkzeug, aber sie hat einen Preis: mehr Klassen, mehr Mapping, mehr Indirektion. Wer sie auf einen einfachen CRUD-Dienst anwendet, schreibt viel Code, der nur Daten von A nach B kopiert.
Was es kostet
- Mapping zwischen Domänenobjekten, Entities und DTOs
- Mehr Interfaces und mehr Dateien, die man beim Lesen verfolgen muss
- Das Team muss das Prinzip verstehen und die Regeln einhalten
Was es bringt
- Fachlogik ist isoliert und gut testbar
- Technische Details sind austauschbar
- Langlebige, komplexe Domänen bleiben beherrschbar
Wann lohnt es sich?
| Situation | Hexagonal? |
|---|---|
| Reiner CRUD-Dienst ohne echte Fachregeln | Eher nein |
| Komplexe Fachlogik, die lange leben soll | Ja |
| Viele externe Schnittstellen, die sich ändern | Ja |
| Prototyp, der evtl. wieder verschwindet | Nein |
| Migration eines gewachsenen Monolithen | Ja, aber schrittweise |
Wichtig
Die Entscheidung gilt pro Modul, nicht pro System. Ein System darf in seinem komplexen Kern hexagonal gebaut sein und trotzdem an den Rändern einfache CRUD-Module enthalten.
Drei Fragen vor der Entscheidung
- Wie komplex sind die Fachregeln wirklich? Wenn sie sich auf „speichern und laden" beschränken, ist der Overhead nicht gerechtfertigt.
- Wie lange soll der Code leben? Je länger, desto eher zahlt sich die Entkopplung aus.
- Kann das Team das tragen? Eine Architektur, die nur eine Person versteht, ist ein Risiko.
Wer unsicher ist, fängt mit einem einfachen Schnitt an und führt Ports erst ein, wenn der Schmerz real wird. Das Refactoring von einer sauberen Schichtung zu Ports und Adaptern ist deutlich günstiger als das Aufräumen eines Systems, das von Anfang an überstrukturiert war.
Die Grundlagen dazu stehen im Artikel Hexagonale Architektur: Ports und Adapter an einem kleinen Beispiel.