Layered, Hexagonal, Onion, Clean: Was diese Architekturen wirklich trennt

Vier Architekturmodelle tauchen in Entwicklerteams ständig auf: Layered, Hexagonal, Onion und Clean. Der Grund ist einfach. Alle vier wollen Ordnung in Anwendungen bringen. Aber sie lösen nicht exakt dasselbe Problem.

Die Verwirrung beginnt oft schon bei den Bildern. Mal sind es Schichten, mal Ringe, mal ein Sechseck. Wer nur auf die Form schaut, verpasst den Punkt. Entscheidend ist, wie Abhängigkeiten laufen und wie stark die Fachlogik vom Rest der Anwendung getrennt wird.

Layered Architecture: simpel, vertraut, oft zu durchlässig

Die klassische Layered Architecture teilt eine Anwendung meist in Präsentation, Business-Logik und Datenzugriff. Das ist leicht zu verstehen und für kleine bis mittlere Systeme oft völlig ausreichend. Teams kommen schnell rein. Viele Frameworks arbeiten ohnehin so.

Das Problem zeigt sich später. Fachlogik rutscht gern in mehrere Schichten. Datenbankmodelle beeinflussen Business-Regeln. Service-Klassen werden zu Sammelstellen für alles Mögliche. Die Architektur ist dann zwar noch geschichtet, aber nicht mehr sauber getrennt.

Layered ist deshalb kein Fehlgriff. Es ist nur oft zu offen für Abkürzungen. Wenn ein Team wenig Disziplin bei Abhängigkeiten hat, wird aus einfacher Struktur schnell technischer Wildwuchs.

Hexagonal Architecture: Schnittstellen zuerst denken

Hexagonal Architecture, oft auch Ports-and-Adapters genannt, setzt an einer anderen Stelle an. Hier steht die Fachlogik im Zentrum. Alles, was von außen kommt oder nach außen geht, läuft über definierte Ports. Adapter binden dann Datenbanken, UIs, APIs oder Message-Broker an.

Der große Vorteil: externe Systeme werden austauschbarer. Wer die Datenbank wechselt oder eine zweite Schnittstelle ergänzt, muss die Kernlogik nicht zerlegen. Tests werden ebenfalls einfacher, weil sich Abhängigkeiten sauber ersetzen lassen.

Hexagonal ist stark, wenn eine Anwendung viele Integrationen hat. Also dort, wo sie mit mehreren Ein- und Ausgängen lebt. Der Preis dafür ist mehr Strukturarbeit am Anfang. Für ein kleines CRUD-Projekt kann das schnell überzogen wirken.

Onion Architecture: der Schutzring um die Domäne

Onion Architecture legt den Schwerpunkt auf die Domäne. In der Mitte sitzt das fachliche Kernmodell, darum gruppieren sich weitere Schichten. Je weiter außen, desto technischer wird es. Die Regel ist klar: Abhängigkeiten zeigen nach innen, nie nach außen.

Das ist besonders sinnvoll, wenn die Fachlogik komplex ist und nicht von Frameworks oder Infrastruktur vereinnahmt werden soll. Die Domäne bleibt das Zentrum der Anwendung, nicht die Datenbank und nicht das Web-Framework.

Onion wird oft dann stark, wenn Domain-Driven Design eine Rolle spielt. Sie schützt Regeln, Prozesse und Modelle besser als ein klassisches Schichtenmodell. Wer aber gar keine ausgeprägte Domäne hat, baut sich damit leicht ein Gerüst, das größer ist als das Problem.

Clean Architecture: der universelle Bauplan mit Use Cases im Fokus

Clean Architecture liegt nahe an Onion und Hexagonal, setzt aber einen eigenen Akzent. Hier stehen Use Cases besonders klar im Vordergrund. Also die Anwendungsfälle, die das System fachlich ausführen soll. Auch hier gilt: äußere Schichten hängen von inneren ab, nie umgekehrt.

Clean Architecture ist attraktiv, weil sie sehr gut erklärt, wo Geschäftsregeln hingehören und wie sich Frameworks aus dem Kern heraushalten lassen. Sie liefert vielen Teams eine gemeinsame Sprache: Entities, Use Cases, Interface Adapter, Frameworks.

Genau da liegt aber auch ein Risiko. Clean wird oft als Vorlage mit vielen Klassen und Projektordnern kopiert, bevor überhaupt klar ist, wie komplex die Anwendung wirklich ist. Dann bleibt von der Idee vor allem zusätzlicher Boilerplate übrig.

Was ist wirklich der Unterschied?

Die drei modernen Varianten lösen ein ähnliches Grundproblem: Business-Logik von Infrastruktur entkoppeln. Die Unterschiede liegen eher im Blickwinkel.

• Layered ordnet nach technischen Schichten.
• Hexagonal ordnet nach Ein- und Ausgängen über Ports und Adapter.
• Onion schützt die Domäne durch konzentrische Abhängigkeitsregeln.
• Clean betont Use Cases und die strikte Trennung von Kern und Außenwelt.

In der Praxis verschwimmen diese Modelle oft. Viele Teams kombinieren sie. Eine Anwendung kann innen eine Onion- oder Clean-Logik haben und nach außen hexagonale Ports nutzen. Das ist kein Widerspruch, sondern oft der vernünftige Weg.

Welche Architektur passt wann?

Layered passt, wenn die Anwendung überschaubar ist, das Team schnell liefern muss und die Fachlogik keine große Eigenwelt bildet.

Hexagonal passt, wenn viele externe Systeme angebunden werden, Austauschbarkeit wichtig ist oder Tests auf Kernlogik-Ebene sauber bleiben sollen.

Onion passt, wenn die Domäne komplex ist und langfristig vor Infrastruktur-Entscheidungen geschützt werden muss.

Clean passt, wenn Teams einen klaren, didaktischen Rahmen für Use Cases und Abhängigkeitsregeln brauchen.

Der häufigste Fehler: Architektur als Identität

Viele Debatten laufen schief, weil Architekturmodelle wie Lager behandelt werden. Clean gegen Hexagonal. Onion gegen Layered. Das ist meist Zeitverschwendung. Wichtiger ist eine einfache Frage: Macht die Struktur Änderungen billiger oder teurer?

Wenn jede kleine Anpassung quer durch Controller, Services und Repositories wandert, ist die Architektur nicht gut genug. Wenn Business-Regeln nur mit echter Datenbank testbar sind, ebenfalls nicht. Wenn für eine kleine Fachanwendung aber erst fünf Interface-Schichten gebaut werden, ist das andere Extrem erreicht.

Gute Architektur senkt Reibung. Sie ist kein Schaubild für Konferenzfolien.

Was davon bleibt

Layered ist der einfache Start. Hexagonal bringt Disziplin an die Systemgrenzen. Onion schützt die Domäne. Clean strukturiert den Kern über klare Anwendungsfälle. Keines dieser Modelle ist automatisch das beste. Aber jedes wird nützlich, wenn es zum Problem passt.

Wer die Unterschiede versteht, diskutiert nicht mehr über Formen. Dann geht es um Wartbarkeit, Testbarkeit und darum, ob Fachlogik die Anwendung führt oder die Infrastruktur.