Clean Architecture — die Abhängigkeitsregel
Clean Architecture, interaktiv dargestellt: Entitäten, Use Cases, Schnittstellen-Adapter und Frameworks — und die Abhängigkeitsregel, die den Kern unabhängig hält.
Clean Architecture ordnet Code in konzentrische Schichten — Entitäten, Use Cases, Schnittstellen-Adapter, Frameworks — unter einer Regel: Abhängigkeiten zeigen immer nach innen, und deshalb hängt der Kern nie von einem Werkzeug ab.
Clean Architecture — die Abhängigkeitsregel
Die interaktive FlowJam-Zeichenfläche zu dieser Erklärung — jede Bahn, jede Zeile und jeder Pfeil oben gehört zu einem echten QueryChart-Diagramm, das Sie öffnen und bearbeiten können.
So lesen Sie diese Darstellung
- Lesen Sie die linke Spalte von oben nach unten als die vier Schichten, vom innersten Ring (Entitäten) bis zum äußersten (Frameworks).
- Lesen Sie dann die rechte Spalte von oben nach unten als die Regel, die sie beherrscht: Abhängigkeiten nach innen, die Adapter in der Mitte, der Kern unberührt.
- Die Pfeile verlaufen dem Sinn nach von außen nach innen, auch wenn sie von links nach rechts gezeichnet sind — der Code jeder äußeren Schicht hängt von der Schicht darin ab.
Die vier Schichten
„Entitäten — unternehmensweite Geschäftsregeln“ ist der innerste Ring: Objekte und Regeln, die es unabhängig davon gibt, wie die Anwendung ausgeliefert wird — ein Kunde, eine Rechnung, die Regel, dass eine Rechnung nicht zweimal bezahlt werden kann. „Use Cases — anwendungsspezifische Regeln“ orchestriert Entitäten für ein Szenario der Anwendung. „Schnittstellen-Adapter — Controller, Presenter“ übersetzt zwischen den Use Cases und der Außenwelt, und „Frameworks und Treiber — UI, Datenbank, Web“ ist der äußere Ring der Werkzeuge.
Die Abhängigkeitsregel
„Abhängigkeiten zeigen nach innen, nie nach außen“ ist die eine Regel, die durchzusetzen diese ganze Architektur da ist: Abhängigkeiten im Quellcode verlaufen immer nach innen. „Äußere Schichten sprechen über den Adapter, nicht mit dem Kern“ ist der Mechanismus — ein Use Case erklärt eine Schnittstelle zum Speichern einer Rechnung, und der Adapter der Datenbank setzt sie um, sodass der Use Case die Bibliothek der Datenbank nie importiert.
Der Gewinn
„Frameworks tauschen, ohne den Kern zu berühren“ und „Der Kern importiert nie ein Framework“ sind der Test, ob die Regel eingehalten wurde: Wechseln Sie von einer Datenbank oder Oberfläche zur nächsten, und an den Entitäten und Use Cases ändert sich nichts. Genau das ist das Wertangebot — der wichtigste, teuerste Code ist vom ersetzbarsten abgeschirmt.
Wichtige Zusammenhänge und Erkenntnisse
- Abhängigkeiten zeigen immer nach innen — diese eine Regel ist die Architektur.
- Der Kern erklärt Schnittstellen, die äußeren Ringe setzen sie um — der Adapter ist die Nahtstelle.
- Entitäten und Use Cases sind von Bauart her unabhängig von Frameworks.
- Der Gewinn ist Ersetzbarkeit: Oberfläche, Datenbank oder Web-Framework tauschen, ohne den Kern anzufassen.
- Bei Clean Architecture geht es um die Richtung der Abhängigkeiten, nicht um die Zahl der Schichten.
Wann Sie diese Darstellung nutzen
- Einem Team die Abhängigkeitsregel vermitteln, bevor es eine große Codebasis strukturiert.
- Eine Architektur prüfen: Ein Use Case, der eine Bibliothek für Oberfläche oder Datenbank importiert, verstößt gegen die Regel, und auf der Zeichenfläche ist das sichtbar.
- Eine Neuentwicklung oder Migration planen — die Zeichenfläche zeigt, welche Schichten überleben müssen und welche ersetzt werden können.
So funktioniert es
Benennen Sie die Schichten auf Ihren Stack um
Ersetzen Sie die allgemeinen Ringnamen durch Ihre echten — Ihre Entitäten, Ihre Klassen der Use Cases, Ihre Controller und Gateways, Ihre tatsächlichen Frameworks für Oberfläche und Datenbank.
Zeichnen Sie die Nahtstellen der Schnittstellen
Ergänzen Sie die Schnittstellen, die der Kern erklärt, und welcher Adapter jede davon umsetzt, damit das Diagramm die Nahtstellen dokumentiert, die die Abhängigkeitsregel überquert.
Markieren Sie die Verstöße
Versehen Sie jede Schicht, die derzeit nach außen importiert, mit einer Beschriftung oder einer anderen Form und mit einer Notiz zum Umbau, der das beheben würde — so dient die Zeichenfläche zugleich als Prüfung.
Zeigen Sie einen echten Tausch
Ergänzen Sie einen Zweig, in dem ein äußeres Framework durch ein anderes ersetzt wird und beide über denselben Adapter angebunden sind, endend im unveränderten Kern.
Häufig gestellte Fragen
Was ist Clean Architecture?
Es ist ein Architekturmuster, bekannt gemacht von Robert C. Martin, das Code in konzentrische Schichten ordnet: Entitäten im Zentrum, dann Use Cases, dann Schnittstellen-Adapter, dann Frameworks und Treiber am Rand. Die beherrschende Regel lautet, dass Abhängigkeiten im Quellcode immer nach innen zeigen, sodass die Geschäftsregeln im Kern nie von den Wegen der Auslieferung abhängen — Oberfläche, Datenbank oder Web-Framework.
Was besagt die Abhängigkeitsregel?
Die Abhängigkeitsregel besagt, dass Abhängigkeiten im Quellcode immer nach innen verlaufen müssen: Eine äußere Schicht darf von einer inneren abhängen, nie umgekehrt. Praktisch erklären die inneren Schichten Schnittstellen, und die äußeren setzen sie um, sodass der Code des Kerns nichts von den Werkzeugen am Rand importiert. Die Darstellung zeichnet das als eigene Gruppe, weil jede andere Eigenschaft dieser Architektur daraus folgt.
Wie unterscheidet sich Clean Architecture von einer Schichtenarchitektur?
Auch eine Schichtenarchitektur trennt Zuständigkeiten, aber ihre Abhängigkeiten laufen meist von oben nach unten — die Präsentationsschicht ruft die Serviceschicht auf, diese die Datenschicht. Clean Architecture kehrt das um: Der fachliche Kern sitzt in der Mitte und alles andere hängt von ihm ab, sodass die Richtung der Abhängigkeit das unterscheidende Merkmal ist. Der Pfeil in den Kern hinein macht diesen Unterschied in der Darstellung sichtbar.
Lohnt sich Clean Architecture für ein kleines Projekt?
Nicht immer — der Aufwand kostet mehr, als er einbringt, wenn die Geschäftsregeln trivial sind oder das Team aus einer Person besteht. Das Muster zahlt sich aus, wenn die Geschäftslogik komplex genug ist, um die Werkzeuge überdauern zu müssen, oder wenn sich Oberfläche oder Datenbank voraussichtlich ändern. Die Kästen zum Gewinn nennen die Abwägung ehrlich: Die Sicherheit des Kerns wird mit den Schichten der Adapter erkauft.
Diese Darstellung in QueryChart (FlowJam) bearbeiten
Öffnen Sie genau diese Zeichenfläche zur Clean Architecture als eigenes Diagramm, benennen Sie die Schichten auf Ihre Codebasis um und zeichnen Sie Ihre Abhängigkeiten ein.