Clean Architecture · Mindmaps

Clean Architecture · Mindmaps

Die interaktive MindMap-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 Mindmap

• Beginnen Sie beim Thema in der Mitte und folgen Sie einem farbigen Zweig zu den zugehörigen Ideen.
• Geschwungene Linien zeigen Beziehungen; Pfeile stehen nur dort, wo die Richtung wichtig ist.

Business core

Dieser Zweig verbindet “The innermost circle: objects and rules that exist no matter how the app is delivered — a customer, an invoice, the rule that an invoice cannot be paid twice.”, “The core never imports a framework”.

Use cases

Dieser Zweig verbindet “Use cases orchestrate entities for one application scenario, such as “place an order”. They know about the app but nothing about screens or databases.”, “Because the database and UI are details, replacing them — a migration, a new front-end — leaves the entities and use cases untouched.”.

Adapters

Dieser Zweig verbindet “Adapters translate between the use cases and the outside world: an HTTP controller turns a request into a use-case call, a presenter turns results into a screen.”, “Outer layers talk through the adapter, not to the core”.

Frameworks

Dieser Zweig verbindet “The outermost ring: the tools. React, PostgreSQL, Express — details that can change without the core knowing or caring.”, “The dependency rule: source code dependencies always cross inward. The core declares what it needs (interfaces) and the outer rings implement them.”.

Verbindungen zwischen den Zweigen

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.

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

1. Mittleres Thema anpassen

   Benennen Sie das Thema für Ihr Projekt oder Ihren Unterricht um.

2. Zweige ausbauen

   Bearbeiten Sie Ideen und ergänzen Sie Beispiele oder Notizen.

3. Ideen verbinden

   Zeichnen Sie Verbindungen zwischen Zweigen; Pfeile zeigen eine wichtige Richtung an.

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 Mindmap in QueryChart bearbeiten

Öffnen Sie die Mindmap auf einer bearbeitbaren Leinwand. Verschieben Sie Ideen und ergänzen Sie Zweige und Verbindungen.

Diese Mindmap in QueryChart bearbeiten