Clean Architecture
Einleitung
Clean Architecture strukturiert Anwendungen so, dass Business-Regeln dauerhaft geschützt sind.
Der Kern des Systems:
- kennt keine Frameworks
- kennt keine Datenbank
- kennt keine UI
- kennt keine Infrastruktur
Ziel:
Die Domäne bleibt stabil – alles andere ist austauschbares Detail.
Einordnung
Clean Architecture ist ein Architektur-Stil für Applikationen, kein einzelnes Pattern.
Sie gehört zur Strukturebene (App-intern) und definiert:
- Schichten
- Abhängigkeitsrichtungen
- Verantwortlichkeiten
Sie vereint und systematisiert:
- Hexagonal Architecture
- Onion Architecture
- Screaming Architecture
Zentrales Prinzip: Die Dependency Rule
Abhängigkeiten dürfen ausschließlich nach innen zeigen.
Innere Schichten:
- dürfen nichts über äußere wissen
Äußere Schichten:
- dürfen innere kennen
Struktur
1️⃣ Entities (Enterprise Business Rules)
- Kernregeln der Domäne
- absolut stabil
- framework-unabhängig
2️⃣ Use Cases (Application Business Rules)
- Orchestrieren Entities
- definieren Anwendungsfälle
- enthalten keine technischen Details
3️⃣ Interface Adapters
- Controller
- Presenters
- Gateways
- Repository-Implementierungen
Übersetzen zwischen innen und außen.
4️⃣ Frameworks & Drivers
- Web Framework
- ORM
- Datenbank
- Messaging
- UI
Diese Schicht ist austauschbar.
Wichtige Klarstellung
Clean Architecture bedeutet nicht:
„Presentation → Business → Model“ als starre Kette.
Sondern:
Strukturierte Abhängigkeitsrichtung zum Schutz des Kerns.
Vorteile
- Sehr hohe Testbarkeit
- Framework-Unabhängigkeit
- Langfristige Wartbarkeit
- Technologiewechsel ohne Core-Refactoring
- Reduzierte Legacy-Erosion
Risiken / typische Fallstricke
1️⃣ Überabstraktion
Interfaces ohne echten Austauschbedarf → unnötige Komplexität.
2️⃣ Falsche Port-Definition
Wenn Framework-Typen in Use Cases landen → Dependency Rule verletzt.
3️⃣ Dogmatische Schichtung
Wenn jede kleine App in vier Layer gezwungen wird → unnötiger Overhead.
Wann sinnvoll?
- Komplexe Domänen
- Langfristige Systeme
- Hohe Testanforderungen
- Austauschbare Infrastruktur
Wann weniger sinnvoll?
- Kleine CRUD-App
- Kurzlebiges MVP
- Geringe Business-Komplexität
Abgrenzung zu verwandten Stilen
| Stil | Fokus |
|---|---|
| Hexagonal | Ports & Adapter |
| Onion | Schichtenmodell |
| Clean Architecture | Dependency Rule + Schichtenvereinheitlichung |
Clean Architecture ist eher ein Meta-Stil, der diese Ansätze strukturell bündelt.
Strategische Perspektive
Clean Architecture schützt:
- Domänenlogik
- Investitionen in Business-Regeln
- langfristige Evolvierbarkeit
Sie verschiebt Komplexität:
von der Domäne zur Struktur.
Fazit
Clean Architecture ist kein Selbstzweck.
Sie ist sinnvoll, wenn:
die Business-Regeln wichtiger sind als das Framework.
In kleinen Systemen ist sie optional. In langlebigen Plattformen ist sie oft strategisch entscheidend.
Quellen
- Robert C. Martin: The Clean Architecture, 2012.
- Robert C. Martin: Clean Architecture, Prentice Hall, 2017.