Wichtige Erkenntnisse
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
Zuletzt aktualisiert:
FAQ
What's Clean Architecture about?
- Focus on Software Structure: Clean Architecture by Robert C. Martin emphasizes creating systems that are easy to develop, maintain, and deploy through effective software architecture.
- Timeless Principles: It outlines principles like SOLID, applicable across various programming paradigms, to guide developers in writing clean, maintainable code.
- Separation of Concerns: The book advocates for separating business rules from technical details, enhancing flexibility and adaptability in software design.
Why should I read Clean Architecture?
- Improve Software Design Skills: The book enhances understanding of software architecture, providing practical advice for real-world projects.
- Timeless Knowledge: Its principles are not tied to specific technologies, ensuring relevance throughout your career.
- Real-World Examples: Martin shares insights from his extensive experience, offering relatable examples and case studies to simplify complex concepts.
What are the key takeaways of Clean Architecture?
- Architecture is a Shape: Software architecture is defined by component division and communication, facilitating development and maintenance.
- Decouple Business Rules: Emphasizes separating business rules from technical details for easier changes and adaptations.
- Leave Options Open: Good architecture defers technical decisions, allowing flexibility to adapt to changing requirements.
What are the SOLID principles mentioned in Clean Architecture?
- Single Responsibility Principle (SRP): A class should have one reason to change, reducing complexity and easing maintenance.
- Open-Closed Principle (OCP): Software entities should be open for extension but closed for modification, minimizing bug risks.
- Liskov Substitution Principle (LSP): Subtypes must be substitutable for their base types without altering program correctness.
What is the Dependency Inversion Principle (DIP) in Clean Architecture?
- High-Level Modules: DIP states high-level modules should not depend on low-level modules; both should depend on abstractions.
- Abstractions Over Details: Depending on abstractions rather than concrete implementations makes systems easier to modify and extend.
- Use of Interfaces: Encourages using interfaces to define contracts between components, enhancing testing and maintenance.
How does Clean Architecture define good software architecture?
- Support for Use Cases: Good architecture must support intended use cases, making them clear and visible within the structure.
- Minimize Human Resources: It should minimize resources required for development, deployment, and maintenance through careful design.
- Leave Options Open: A well-designed architecture keeps options open for future changes, crucial for long-term success.
What is the significance of boundaries in Clean Architecture?
- Separation of Concerns: Boundaries separate system components, ensuring changes in one area don't adversely affect others.
- Control Over Dependencies: Managing dependencies across boundaries prevents disruptions, leading to a stable system.
- Facilitate Independent Development: Boundaries allow teams to work independently, enhancing productivity and reducing conflicts.
What is the "Screaming Architecture" concept in Clean Architecture?
- Architecture Reflects Intent: "Screaming Architecture" means the system's architecture should clearly communicate its purpose and functionality.
- Use Case Driven: Good architecture is driven by use cases, maintaining clarity and purpose throughout development.
- Avoid Framework Dependency: Architecture should be centered around business needs, not dictated by frameworks or tools.
How does Clean Architecture address testing?
- Testable Architectures: Emphasizes architectures that allow unit testing of business rules without external systems running.
- Humble Object Pattern: Separates hard-to-test code from testable code, focusing on logic without UI or framework complexities.
- Testing API: Suggests creating a testing API to bypass security constraints, enhancing the ability to test various scenarios.
How does Clean Architecture differentiate between the web and the architecture of a system?
- Web as a Delivery Mechanism: The web is viewed as a delivery mechanism, not a defining aspect of system architecture.
- Decoupling Delivery from Logic: Treating the web as a detail allows designing systems agnostic to delivery methods.
- Focus on Business Logic: Prioritizes business logic and use cases over web delivery specifics, ensuring core functionality remains intact.
What are the risks of using frameworks according to Clean Architecture?
- Tight Coupling: Frameworks can lead to tight coupling, making technology switches difficult.
- Overhead and Complexity: Heavy reliance on frameworks can introduce unnecessary complexity and hinder performance.
- Loss of Control: Over-reliance on frameworks can lead to a rigid system, making changes and adaptations challenging.
What are the best quotes from Clean Architecture and what do they mean?
- "Your architecture should tell readers about the system, not about the frameworks you used in your system.": Emphasizes architecture reflecting business domain and use cases, not technologies.
- "Frameworks are tools, not ways of life.": Reminds developers to maintain control over architecture, not be overly reliant on frameworks.
- "A good architecture makes it unnecessary to decide on Rails, or Spring, or Hibernate, or Tomcat, or MySQL, until much later in the project.": Highlights deferring technology decisions until architecture is established, promoting flexibility.
Rezensionen
Saubere Architektur: Ein Handbuch für Softwarestruktur und -design erhält gemischte Bewertungen. Viele loben den Fokus auf SOLID-Prinzipien und Entkopplung, während andere es als repetitiv und mangelnd an praktischen Beispielen empfinden. Einige Leser schätzen den historischen Kontext und die Anekdoten, während andere der Meinung sind, dass sie vom Kerninhalt ablenken. Das Buch wird allgemein als hilfreich für das Verständnis von hochrangigen Architekturkonzepten angesehen, aber die Meinungen über seine Nützlichkeit für Anfänger im Vergleich zu erfahrenen Entwicklern gehen auseinander. Mehrere Rezensenten bemerken, dass der Inhalt des Buches prägnanter hätte vermittelt werden können.
