Clean Architecture

[hfanieng]

Clean Architecture

(geprägt von Robert C. Martin, auch bekannt als Uncle Bob) ist ein Architekturmuster, bei dem der Fokus auf einer klaren Trennung von Zuständigkeiten und einer losen Kopplung zwischen den Komponenten eines Softwaresystems liegt. Damit sollen Systeme langfristig wart- und erweiterbar bleiben. Oft wird auch von Hexagonal Architecture, Onion Architecture oder Ports-and-Adapters-Architektur gesprochen, die alle ähnliche Prinzipien verfolgen.

---

Grundprinzipien in Clean Architecture

• Trennung der Schichten (Layered Architecture):
  • Der Kern (Domain) bleibt unabhängig von technischen Details. Man trennt die fachliche Logik (Domain) von der technischen Infrastruktur (z.B. Datenbanken, UI-Frameworks).
• Dependency Rule (Abhängigkeitsregel):
  • Der Datenfluss darf nur von außen nach innen gehen. Das bedeutet, dass äußere Schichten zwar Klassen aus inneren Schichten nutzen dürfen, aber umgekehrt nicht. Die innere Schicht (Domain) kennt also keine Details über Datenbanken, UIs oder sonstige Frameworks.
• Ziel:
  • Fachliche Logik (Domain und Use Cases) stehen im Fokus.
  • Technische Details werden austauschbar gehalten (z.B. verschiedene Datenbanken oder UI-Frameworks).
  • Vereinfachte Wartbarkeit, da Änderungen in einer Schicht die anderen weniger (oder gar nicht) beeinflussen.

---

Typische Schichten in Clean Architecture

• Domain Entities:
  • Reine, unabhängige Klassen/Strukturen, die die wesentlichen Geschäftsobjekte (z.B. Kunde, Rechnung, Produkt) und ihre Regeln repräsentieren.
  • Enthalten keinerlei Logik über Datenbankzugriff, APIs oder andere externe Systeme.
• Use Cases / Application Services:
  • Enthalten die Geschäftslogik in Form von Anwendungsfällen (z.B. „Erstelle eine neue Bestellung“, „Berechne den Gesamtpreis“, „Prüfe Lagerbestand“).
  • Koordinieren das Zusammenspiel zwischen Domain Entities.
  • Kennen zwar die Domain Entities, aber keine Details zu Datenbank oder UI.
  • Enthalten ggf. Schnittstellen (Interfaces), die Infrastruktur-Schichten implementieren müssen (z.B. ein OrderRepository, das in einer anderen Schicht konfiguriert wird).
• Interface Adapters (oder Adapters-Schicht):
  • Bieten die konkrete Implementierung für die Schnittstellen aus der Use-Case-Schicht (z.B. OrderRepositoryImpl für das OrderRepository).
  • Hier passiert z.B. die Umsetzung von Datenbankzugriff (z.B. via ORM oder SQL) oder die Kommunikation mit externen Services (APIs).
  • Enthält außerdem Konvertierungslogik zwischen Domain-Objekten und DTOs (Data Transfer Objects), falls benötigt.
• Frameworks and Drivers (oder Delivery-Schicht):
  • Ganz außen liegen UI-Frameworks, Web-/REST-Controller, CLI, Datenbanktreiber usw.
  • Sie „bedienen“ sich der Use-Case-Schicht. So kann man z.B. den Use Case „Erstelle eine neue Bestellung“ von einem REST-Endpunkt aus aufrufen oder einer Benutzeroberfläche.
  • Enthält also alles, was die Anwendung letztlich „nach außen“ exponiert oder in Anspruch nimmt.

---

Schritt-für-Schritt-Vorgehen

• Domain verstehen und abgrenzen
  • Erstelle zunächst ein Domain-Modell, definiere die Hauptentitäten (z.B. Kunde, Bestellung, Produkt).
  • Sammle die wichtigsten Geschäftsregeln (z.B. „Eine Bestellung darf nur erstellt werden, wenn…“).
  • Orientiere dich bei Bedarf an Domain-Driven Design (DDD).
• Use Cases definieren
  • Lege klar fest, welche Anwendungsfälle deine Software abdecken soll (z.B. „Erfasse Bestellung“, „Zeige Bestellhistorie an“, „Suche Produkt“).
  • Schreibe je Use Case die erforderliche Eingabe (Input), das erwartete Ergebnis (Output) und die Geschäftslogik auf.
  • Die Use Cases stehen zwischen Benutzerschnittstelle und Domain.
• Schnittstellen (Interfaces) für Infrastruktur definieren
  • In Clean Architecture liegen die Interfaces für z.B. Datenbankzugriff (z.B. IOrderRepository) in der Use-Case- oder Domain-Schicht.
  • Die Use Cases (Application Layer) rufen diese Interfaces auf, ohne Details zu kennen.
  • Die konkrete Implementierung passiert später in der Adapter-Schicht (Infrastruktur).
• Domain Entities und Use-Case-Klassen umsetzen
  • Jetzt implementierst du die Kernlogik in sauber gekapselten Domänenobjekten (Entities) und Use Cases.
  • Halte dich strikt an die Devise: Keine technischen Abhängigkeiten hier!
• Interface Adapters (Infrastruktur, Datenbank, APIs)
  • Erst danach implementierst du die konkreten Adapter-Klassen, die z.B. mit einer Datenbank interagieren (Repository-Implementierungen) oder mit anderen externen Diensten sprechen.
  • Hier hast du u.a. Mappings/DTOs, um Domain-Objekte für die Datenbank fit zu machen (z.B. Umwandlung in Tabellenzeilen, Dokumente, etc.).
• Delivery-Schicht / Präsentation / UI
  • Schließlich integrierst du eine UI (Web, Mobile, Desktop) oder Endpunkte (z.B. REST-Controller).
  • Diese rufen wiederum die Use Cases auf und transportieren die Daten an Endnutzer oder andere Services.
  • Auch hier sollte gelten: UI kennt die Use Cases, aber nicht umgekehrt.

---

Tipps für eine Clean-Architecture-Implementierung

• Keep it simple – erst Komplexität, wenn nötig
  • Baue die Schichten nach und nach auf. Oft reicht eine minimalistische Schichtenarchitektur am Anfang, die erst bei wachsender Komplexität aufgesplittet wird.
• Achte auf klare Boundaries
  • Vermeide, dass Code aus den Use Cases oder Domain-Klassen in die Infrastruktur-Details „hineinschaut“.
  • Halte dich an das Prinzip: Was von der Architektur her innen ist, kennt nicht das, was außen liegt.
• Entkopple dich von Frameworks
  • Frameworks (Spring, Laravel, Angular, React, Flutter etc.) gehören in die äußeren Schichten.
  • Nutze sie, aber z.B. in den Adaptern, nicht im Kern. So kannst du bei Bedarf wechseln.
• Testbarkeit
  • Ein großer Vorteil von Clean Architecture: Deine Domain- und Use-Case-Logik kann isoliert und einfach getestet werden, ohne eine Datenbank oder externe Services zu benötigen.
  • Nutze Mocks/Stubs, um die Infrastruktur zu simulieren.
• Versionierung und Erweiterbarkeit
  • Durch die saubere Trennung lassen sich einzelne Schichten einfacher austauschen.
  • Wenn du z.B. eine andere Datenbank oder einen anderen externen Dienst nutzen willst, tauschst du die Adapter-Implementierungen aus – an der Domain- und Use-Case-Logik ändert sich nichts.
• Refaktorieren und Feedback einholen
  • Bei neuen Features oder sich ändernden Anforderungen lohnt es sich, regelmäßig die Schichten zu überprüfen: Wo kommen neue Entities, Use Cases oder Adapter hinzu? Wo kann man etwas aufräumen?
  • Erhalte Feedback vom Team, um die Architektur konsequent weiterzuentwickeln.

---

Zusammenfassung

• Um ein neues Softwareprojekt mit einer Clean Architecture anzugehen:
  • Domain und Use Cases in den Fokus stellen (Geschäftslogik sauber definieren).
  • Schnittstellen (Interfaces) für Datenbank, externe Services etc. abstecken.
  • Konkrete Implementierungen (Adapter) erst nach Definition der Interfaces erstellen.
  • UI/Framework als äußerste Schicht anbinden – es sollte nur die Use Cases aufrufen und nicht umgekehrt.
• Durch diese klaren Trennlinien stellst du sicher, dass dein System auch bei steigender Komplexität stabil, wartbar und erweiterbar bleibt.