Clean Architecture

1. Softwarearchitektur zielt darauf ab, menschliche Ressourcen zu minimieren und die Produktivität zu maximieren

Das Ziel der Softwarearchitektur ist es, die benötigten menschlichen Ressourcen für den Aufbau und die Wartung des erforderlichen Systems zu minimieren.

Architektonische Entscheidungen sind wichtig. Gute Architektur reduziert den Aufwand für die Entwicklung, Bereitstellung und Wartung von Softwaresystemen. Sie ermöglicht es Teams, unabhängig zu arbeiten, minimiert die Auswirkungen von Änderungen und erlaubt es dem System, sich im Laufe der Zeit weiterzuentwickeln.

Wichtige Aspekte guter Architektur:

• Trennung der Anliegen
• Abhängigkeitsmanagement
• Abstraktion von Implementierungsdetails
• Flexibilität zur Aufnahme zukünftiger Änderungen

Durch die Fokussierung auf diese Aspekte können Architekten Systeme schaffen, die leichter zu verstehen, zu modifizieren und zu erweitern sind, was letztendlich zu erhöhter Produktivität und reduzierten Kosten über die Lebensdauer des Systems führt.

2. Saubere Architektur trennt Geschäftsregeln von externen Details

Das Zentrum Ihrer Anwendung ist nicht die Datenbank. Es sind auch nicht eines oder mehrere der Frameworks, die Sie möglicherweise verwenden. Das Zentrum Ihrer Anwendung sind die Anwendungsfälle Ihrer Anwendung.

Geschäftsregeln sind der Kern. Saubere Architektur organisiert den Code in konzentrischen Kreisen, wobei die Geschäftsregeln im Zentrum und die Implementierungsdetails in den äußeren Schichten liegen. Diese Trennung ermöglicht es, dass die Kern-Geschäftslogik von Änderungen externer Faktoren wie Datenbanken, Benutzeroberflächen oder Frameworks unberührt bleibt.

Wichtige Schichten in der sauberen Architektur:

• Entitäten: Unternehmensweite Geschäftsregeln
• Anwendungsfälle: Anwendungsspezifische Geschäftsregeln
• Schnittstellenadapter: Konvertieren Daten zwischen Anwendungsfällen und externen Agenturen
• Frameworks und Treiber: Externe Werkzeuge und Technologien

Durch die Einhaltung dieser Struktur können Entwickler Systeme schaffen, die:

• Flexibler und anpassungsfähiger an Änderungen sind
• Leichter zu testen und zu warten sind
• Weniger abhängig von spezifischen Technologien oder Frameworks sind

3. SOLID-Prinzipien leiten die Erstellung flexibler, wartbarer Systeme

Die SOLID-Prinzipien sagen uns, wie wir unsere Funktionen und Datenstrukturen in Klassen anordnen und wie diese Klassen miteinander verbunden sein sollten.

SOLID verbessert die Modularität. Diese fünf Prinzipien bieten Richtlinien für die Erstellung von Softwaresystemen, die verständlicher, flexibler und wartbarer sind. Sie helfen Entwicklern, Code zu entwerfen, der widerstandsfähig gegen Änderungen und leicht erweiterbar ist.

Die SOLID-Prinzipien sind:

• Single Responsibility Principle: Eine Klasse sollte nur einen Grund zur Änderung haben
• Open-Closed Principle: Softwareeinheiten sollten für Erweiterungen offen, aber für Modifikationen geschlossen sein
• Liskov Substitution Principle: Objekte einer Oberklasse sollten durch Objekte ihrer Unterklassen ersetzt werden können, ohne die Korrektheit des Programms zu beeinträchtigen
• Interface Segregation Principle: Viele client-spezifische Schnittstellen sind besser als eine allgemeine Schnittstelle
• Dependency Inversion Principle: Hochrangige Module sollten nicht von niederrangigen Modulen abhängen; beide sollten von Abstraktionen abhängen

Durch die Anwendung dieser Prinzipien können Entwickler robustere und skalierbarere Softwarearchitekturen schaffen, die sich im Laufe der Zeit an veränderte Anforderungen anpassen können.

4. Komponenten sind die Bausteine einer sauberen Architektur

Komponenten sind die Einheiten der Bereitstellung. Sie sind die kleinsten Einheiten, die als Teil eines Systems bereitgestellt werden können.

Modulares Design ermöglicht Flexibilität. Komponenten in der sauberen Architektur sind unabhängig bereitstellbare und entwickelbare Teile des Systems. Sie kapseln verwandte Funktionalitäten und haben gut definierte Schnittstellen, was die Wartung und Modifikation des Systems erleichtert.

Wichtige Merkmale gut gestalteter Komponenten:

• Hohe Kohäsion: Verwandte Funktionalitäten sind zusammengefasst
• Geringe Kopplung: Minimale Abhängigkeiten zwischen Komponenten
• Klare Schnittstellen: Gut definierte Interaktionsmethoden
• Unabhängige Bereitstellbarkeit: Können aktualisiert oder ersetzt werden, ohne andere Teile des Systems zu beeinflussen

Durch die Organisation von Systemen in Komponenten können Architekten:

• Parallele Entwicklung durch verschiedene Teams erleichtern
• Einfacheres Testen und Debuggen ermöglichen
• Inkrementelle Updates und Verbesserungen des Systems erlauben
• Die Skalierbarkeit und Wartbarkeit des Gesamtsystems verbessern

5. Grenzen definieren und schützen die Kern-Geschäftslogik

An jeder architektonischen Grenze finden wir wahrscheinlich irgendwo das Muster des bescheidenen Objekts.

Grenzen schützen den Kern. Architektonische Grenzen in der sauberen Architektur trennen verschiedene Anliegen, insbesondere zwischen Geschäftslogik und Implementierungsdetails. Diese Grenzen helfen, die Unabhängigkeit der Kern-Geschäftsregeln von externen Änderungen zu bewahren.

Wichtige Aspekte architektonischer Grenzen:

• Verwendung von Schnittstellen zur Definition von Interaktionen zwischen Schichten
• Abhängigkeitsinversion, um sicherzustellen, dass Abhängigkeiten nach innen zeigen
• Datenübertragungsobjekte zum Übermitteln von Informationen über Grenzen hinweg
• Bescheidene Objekte, um testbares Verhalten von schwer zu testenden Komponenten zu trennen

Durch die Etablierung klarer Grenzen können Architekten:

• Die Auswirkungen von Änderungen in externen Systemen oder Technologien minimieren
• Einfacheres Testen der Kern-Geschäftslogik ermöglichen
• Den Austausch von Implementierungsdetails ermöglichen, ohne das Kernsystem zu beeinflussen
• Die Flexibilität und Anpassungsfähigkeit des Gesamtsystems verbessern

6. Saubere Architektur erleichtert testgetriebene Entwicklung und unabhängige Bereitstellung

Eine gute Architektur macht das System leicht änderbar, in all den Weisen, in denen es geändert werden muss, indem sie Optionen offen lässt.

Testbarkeit und Flexibilität sind entscheidend. Saubere Architektur fördert Praktiken, die Systeme leichter testbar und unabhängig bereitstellbar machen. Durch die Trennung der Anliegen und das Management von Abhängigkeiten wird es einfacher, Unit-Tests für die Kern-Geschäftslogik zu schreiben und verschiedene Komponenten des Systems separat bereitzustellen.

Vorteile der sauberen Architektur für Testen und Bereitstellung:

• Kern-Geschäftsregeln können ohne UI-, Datenbank- oder externe Abhängigkeiten getestet werden
• Verschiedene Komponenten können unabhängig bereitgestellt werden, was einfachere Updates ermöglicht
• Änderungen in einem Bereich des Systems haben minimale Auswirkungen auf andere
• Neue Funktionen können mit geringem Risiko bestehender Funktionalitäten hinzugefügt werden

Diese Eigenschaften führen zu:

• Schnelleren Entwicklungszyklen
• Reduziertem Risiko bei Bereitstellungen
• Verbesserter Systemzuverlässigkeit
• Größerer Flexibilität bei der Einführung neuer Technologien oder der Änderung bestehender

7. Frameworks und Datenbanken sind Implementierungsdetails, keine architektonischen Elemente

Frameworks sind Werkzeuge, die verwendet werden sollen, nicht Architekturen, denen man sich anpassen muss.

Kernlogik sollte framework-unabhängig sein. Saubere Architektur behandelt Frameworks und Datenbanken als externe Details, die die Kern-Geschäftslogik nicht beeinflussen sollten. Dieser Ansatz ermöglicht größere Flexibilität bei der Änderung oder Aktualisierung dieser externen Elemente, ohne die Kernfunktionalität des Systems zu beeinträchtigen.

Wichtige Prinzipien für den Umgang mit Frameworks und Datenbanken:

• Behandeln Sie sie als Plugins zur Kern-Geschäftslogik
• Verwenden Sie Abhängigkeitsinversion, um die Kernlogik unabhängig zu halten
• Erstellen Sie Abstraktionen für Datenbankoperationen
• Verzögern Sie Entscheidungen über Frameworks und Datenbanken so lange wie möglich

Vorteile dieses Ansatzes:

• Einfacher, Frameworks und Datenbanken zu ändern oder zu aktualisieren
• Kern-Geschäftslogik bleibt trotz externer Änderungen stabil
• Reduzierte Abhängigkeit von Anbietern
• Verbesserte Testbarkeit der Kernsystemkomponenten

8. Das Web ist nur ein weiterer Liefermechanismus in der sauberen Architektur

Das Web ist ein Liefermechanismus, und Ihre Anwendungsarchitektur sollte es als solchen behandeln.

Geschäftslogik ist lieferunabhängig. In der sauberen Architektur wird das Web als externes Detail behandelt, ähnlich wie Datenbanken oder Frameworks. Diese Perspektive ermöglicht es, dass die Kern-Geschäftslogik unabhängig vom spezifischen Liefermechanismus bleibt, sei es eine Webanwendung, eine Desktop-App oder eine API.

Wichtige Überlegungen für Webanwendungen in der sauberen Architektur:

• Trennen Sie web-spezifischen Code von der Kern-Geschäftslogik
• Verwenden Sie Schnittstellenadapter, um zwischen Webformaten und internen Datenstrukturen zu konvertieren
• Behandeln Sie Web-Frameworks als Plugins zum Kernsystem
• Entwerfen Sie Anwendungsfälle, die unabhängig von web-spezifischen Anliegen sind

Vorteile dieses Ansatzes:

• Einfacher, das System an verschiedene Liefermechanismen anzupassen
• Kern-Geschäftslogik kann über mehrere Plattformen hinweg wiederverwendet werden
• Vereinfachtes Testen der Geschäftsregeln ohne Web-Abhängigkeiten
• Größere Flexibilität bei der Änderung oder Aktualisierung von Webtechnologien

9. Saubere eingebettete Architektur trennt Hardware-Anliegen von der Geschäftslogik

Obwohl Software nicht verschleißt, kann sie von innen heraus durch unkontrollierte Abhängigkeiten von Hardware zerstört werden.

Hardware-Unabhängigkeit ist entscheidend. Saubere eingebettete Architektur wendet die Prinzipien der sauberen Architektur auf eingebettete Systeme an, indem sie hardware-spezifische Anliegen von der Kern-Geschäftslogik trennt. Diese Trennung ermöglicht einfachere Updates der Hardwarekomponenten und verbesserte Portabilität der Software.

Wichtige Elemente der sauberen eingebetteten Architektur:

• Hardware-Abstraktionsschicht (HAL), um hardware-spezifischen Code zu isolieren
• Geräteunabhängige Geschäftslogik
• Klare Schnittstellen zwischen Hardware- und Softwarekomponenten
• Verwendung von Abhängigkeitsinversion zur Verwaltung von Hardware-Abhängigkeiten

Vorteile dieses Ansatzes in eingebetteten Systemen:

• Einfacher, Software auf neue Hardwareplattformen zu portieren
• Vereinfachtes Testen der Kernlogik ohne Hardware-Abhängigkeiten
• Reduzierte Auswirkungen von Hardwareänderungen auf das Gesamtsystem
• Verbesserte Wartbarkeit und Langlebigkeit der eingebetteten Software

10. Microservices und serviceorientierte Architekturen können von den Prinzipien der sauberen Architektur profitieren

Die Architektur eines Systems wird durch Grenzen definiert, die Softwareelemente voneinander trennen und diejenigen auf der einen Seite daran hindern, über diejenigen auf der anderen Seite Bescheid zu wissen.

Saubere Prinzipien gelten in allen Maßstäben. Während saubere Architektur oft im Kontext monolithischer Anwendungen diskutiert wird, können ihre Prinzipien effektiv auf Microservices und serviceorientierte Architekturen angewendet werden. Diese Prinzipien helfen, die Unabhängigkeit und Testbarkeit einzelner Dienste zu bewahren und gleichzeitig die Komplexität verteilter Systeme zu managen.

Anwendung der sauberen Architektur auf Microservices:

• Behandeln Sie jeden Microservice als abgegrenzten Kontext mit eigener sauberer Architektur
• Verwenden Sie gut definierte Schnittstellen für die Kommunikation zwischen Diensten
• Wenden Sie Abhängigkeitsinversion zwischen Diensten an
• Bewahren Sie die unabhängige Bereitstellbarkeit der Dienste

Vorteile der sauberen Architektur in Microservices:

• Verbesserte Modularität und Skalierbarkeit des Gesamtsystems
• Einfacher zu verstehende und zu wartende einzelne Dienste
• Größere Flexibilität bei der Weiterentwicklung und dem Austausch von Diensten
• Reduzierte Kopplung zwischen Diensten, was zu robusteren Systemen führt

Last updated: July 26, 2024