Onion Architecture
Einleitung
Onion Architecture stellt die Domäne konsequent ins Zentrum der Anwendung.
Alle technischen Details – UI, Datenbank, Messaging, Frameworks – liegen außen und dürfen den Kern nicht beeinflussen.
Ziel:
Der Domain-Kern bleibt stabil, unabhängig von Technologie und Infrastruktur.
Einordnung
Onion Architecture ist ein App-internes Strukturmodell.
Sie ist:
- kein Systemstil
- kein Deployment-Pattern
- kein Infrastruktur-Muster
Sie definiert ausschließlich die Abhängigkeitsrichtung innerhalb einer Anwendung.
Zentrales Prinzip
Abhängigkeiten verlaufen ausschließlich von außen nach innen.
Der Kern:
- kennt keine Infrastruktur
- kennt keine Frameworks
- kennt keine UI
Struktur (Konzentrische Ringe)
1️⃣ Domain Model (innerster Ring)
- Entities
- Value Objects
- Domain Rules
- Invarianten
Diese Schicht ist:
- stabil
- technologie-unabhängig
- langlebig
2️⃣ Application Layer
- Use Cases
- Orchestrierung
- Transaktionslogik
Diese Schicht nutzt die Domain, enthält aber keine Infrastruktur.
3️⃣ Infrastructure / UI (äußere Ringe)
- Datenbankzugriff
- Messaging
- REST-Controller
- Frameworks
Diese implementieren Interfaces, die im Inneren definiert sind.
Charakteristische Merkmale
- Konzentrische Struktur statt linearer Layer
- Abhängigkeitsregel zum Zentrum
- Infrastruktur ist Detail
- Domain ist Kern
Vorteile
- Sehr hohe Testbarkeit
- Schutz der Business-Regeln
- Technologieaustausch möglich
- Klare Architekturdisziplin
Risiken / typische Fallstricke
1️⃣ Überabstraktion
Wenn kleine Systeme künstlich geschichtet werden → unnötiger Overhead.
2️⃣ Falsche Interface-Positionierung
Wenn Infrastruktur-Interfaces außerhalb definiert werden → Dependency Rule verletzt.
3️⃣ Domain Leakage
Wenn technische Details in Domain-Objekte gelangen → Kern verliert Reinheit.
Wann sinnvoll?
- Komplexe Business-Systeme
- Langlebige Plattformen
- Hohe Testanforderungen
- Strategisch wertvolle Domänenlogik
Wann weniger sinnvoll?
- Kleine CRUD-Anwendung
- Kurzlebiges Tool
- Geringe Business-Komplexität
Abgrenzung zu verwandten Ansätzen
| Ansatz | Fokus |
|---|---|
| Layered | Horizontale Schichten |
| Hexagonal | Ports & Adapter, symmetrische Außenwelt |
| Clean | Formalisierte Dependency Rule + Schichten |
| Onion | Konzentrische Ringe mit Domain im Zentrum |
Onion und Hexagonal sind sehr ähnlich. Clean Architecture kann als formalisierte Weiterentwicklung beider gesehen werden.
Strategische Perspektive
Onion Architecture schützt:
- Investitionen in Domänenwissen
- langfristige Wartbarkeit
- Architektur-Stabilität
Sie zwingt zur Disziplin in der Abhängigkeitsstruktur.
Fazit
Onion Architecture ist besonders stark, wenn:
die Domäne wertvoller ist als das Framework.
Für kleine Systeme ist sie optional. Für komplexe Plattformen oft strategisch sinnvoll.
Quellen
- Jeffrey Palermo: The Onion Architecture, 2008.