mitp Clean Architecture Softwaredesign Übersetzung Das Praxis-Handbuch für professionelles Regeln und Paradigmen Robert C. Martin

Transkript

1 Robert C. Martin Clean Architecture Das Praxis-Handbuch für professionelles Softwaredesign Regeln und Paradigmen für effiziente Softwarestrukturen Übersetzung aus dem Amerikanischen von Maren Feilen und Knut Lorenzen mitp

2 Inhaltsverzeichnis Vorwort 15 Einleitung 19 Über den Autor 23 Danksagung 24 Teil I Einführung 25 1 Was bedeuten»design«und»architektur«? Das Ziel? Fallstudie Die Signatur des Chaos Die Perspektive der Unternehmensleitung Was ist schiefgelaufen? Fazit 37 2 Die Geschichte zweier Werte Verhalten Architektur Der größere Wert Das Eisenhower-Prinzip Der Kampffür die Architektur 43 Teil II Die ersten Bausteine setzen: Programmierparadigmen 45 3 Die Paradigmen Strukturierte Programmierung Objektorientierte Programmierung Funktionale Programmierung Denkanstöße Fazit 49

3 Inhaltsverzeichnis 4 Strukturierte Programmierung Die Beweisführung Eine»schädliche«Proklamation Funktionale Dekomposition Keine formalen Beweise Wissenschaft als Rettung Tests Fazit 57 5 Objektorientierte Programmierung Datenkapselung? Vererbung? Polymorphie Die Macht der Polymorphie Abhängigkeitsumkehr Fazit 71 6 Funktionale Programmierung Quadrierung von Integern Unveränderbarkeit und Architektur Unterteilung der Veränderbarkeit Event Sourcing Fazit 79 Teil III Designprinzipien 81 7 SRP: Das Single-Responsibility-Prinzip Symptom 1: Versehentliche Duplizierung Symptom 2: Merges Lösungen Fazit 90 8 OCP: Das Open-Closed-Prinzip Ein Gedankenexperiment Richtungssteuerung Information Hiding Fazit 96 9 LSP: Das Liskov'sche Substitutionsprinzip Gesteuerte Nutzung der Vererbung 98 6

4 Inhaltsverzeichnis 9.2 Das Quadrat-Rechteck-Problem Das LSP und die Softwarearchitektur Beispiel für einen Verstoß gegen das LSP Fazit ISP: Das Interface-Segregation-Prinzip Das ISP und die Programmiersprachen Das ISP und die Softwarearchitektur Fazit DIP: Das Dependency-Inversion-Prinzip Stabile Abstraktionen Factories Konkrete Komponenten Fazit HO Teil IV Komponenten prinzipiell m 12 Komponenten Eine kurze Historie der Komponenten Relokatierbarkeit Linker Fazit Komponentenkohäsion REP: Das Reuse-Release-Equivalence-Prinzip CCP: Das Common-Closure-Prinzip Ähnlichkeiten mit dem SRP CRP: Das Common-Reuse-Prinzip Relation zum ISP Das Spannungsdiagramm für die Komponentenkohäsion Fazit Komponentenkopplung ADP: Das Acyclic-Dependencies-Prinzip Der wöchentliche Build Abhängigkeitszyklen abschaffen Auswirkung eines Zyklus in einem Komponenten abhängigkeitsgraphen Den Zyklus durchbrechen Jitters (Fluktuationen) 135

5 Inhaltsverzeichnis 14.2 Top-down-Design SDP: Das Stable-Dependencies-Prinzip Stabilität Stabilitätsmetriken Nicht alle Komponenten sollten stabil sein Abstrakte Komponenten SAP: Das Stable-Abstractions-Prinzip Wo werden die übergeordneten Richtlinien hinterlegt? Einführung in das SAP (Stable-Abstractions-Prinzip) Bemessung der Abstraktion Die Hauptreihe Die»Zone of Pain« Die»Zone of Uselessness« Die Ausschlusszonen vermeiden Abstand von der Hauptreihe Fazit 149 TeilV Sortwarearchitektur Was ist Softwarearchitektur? Entwicklung Deployment Betrieb Instandhaltung Optionen offenhalten Geräteunabhängigkeit JunkMail Physische Adressierung Fazit Unabhängigkeit UseCases Betrieb Entwicklung Deployment Optionen offenhalten Layer entkoppeln Use Cases entkoppeln Entkopplungsmodi 170 8

6 und Inhaltsverzeichnis 16.9 Unabhängige Entwickelbarkeit Unabhängige Deploybarkeit Duplizierung Entkopplungsmodi (zum Zweiten) Welcher Modus ist am besten geeignet? Fazit Grenzen: Linien ziehen Ein paar traurige Geschichten FitNesse Welche Grenzen sollten Sie ziehen - wann? Wie verhält es sich mit der Ein- und Ausgabe? Plug-in-Architektur Das Plug-in-Argument Fazit Anatomie der Grenzen Grenzüberschreitungen Der gefürchtete Monolith Deployment-Komponenten Threads Lokale Prozesse Services Fazit Richtlinien und Ebenen Ebene Fazit Geschäftsregeln Entitäten Use Cases Request-and-Response-Modelle Fazit Die schreiende Softwarearchitektur Das Thema einer Architektur Der Zweck einer Softwarearchitektur Aber was ist mit dem Web? Frameworks sind Tools, keine Lebenseinstellung Testfähige Architekturen Fazit 210

7 große Inhaltsverzeichnis 22 Die saubere Architektur Die Abhängigkeitsregel (Dependency Rule) Entitäten UseCases Schnittstellenadapter Frameworks und Treiber Nur vier Kreise? Grenzen überschreiten Welche Daten überqueren die Grenzlinien? Ein typisches Beispiel Fazit Presenters und»humble Objects« Das Pattern»Humble Object« Presenters und Views Das Testen und die Softwarearchitektur Datenbank-Gateways Data Mappers Service Listeners Fazit Partielle Grenzen Den letzten Schritt weglassen Eindimensionale Grenzen Fassaden Fazit Layer und Grenzen Hunt the Wumpus Saubere Architektur? Datenstromüberschreitungen Datenströme teilen Fazit Die Komponente Main Das ultimative Detail Fazit Services - und kleine Servicearchitektur?

8 27.2 Vorteile der Services? Denkfalle: Entkopplung Denkfalle: Unabhängige Entwickel- und Deploybarkeit Das Kätzchen-Problem Objekte als Rettung Komponentenbasierte Services Cross-Cutting Concerns Fazit Die Testgrenze Tests als Systemkomponenten Design für Testfähigkeit Die Test-API Strukturelle Kopplung Sicherheit Fazit Saubere eingebettete Architektur App-Eignungstest Der Flaschenhals der Zielhardware Eine saubere eingebettete Architektur ist eine testfähige eingebettete Architektur Offenbaren Sie dem HAL-User keine Hardwaredetails Fazit 269 Teil VI Details Die Datenbank ist ein Detail Relationale Datenbanken Warum sind Datenbanksysteme so weit verbreitet? Was wäre, wenn es keine Festplatten gäbe? Details Und was ist mit der Performance? Anekdote Fazit Das Web ist ein Detail Der immerwährende Pendelausschlag Quintessenz Fazit 282

9 Inhaltsverzeichnis 32 Ein Framework ist ein Detail Framework-Autoren Asymmetrische Ehe Die Risiken Die Lösung Hiermit erkläre ich euch zu Fazit Fallstudie: Software für den Verkaufvon Videos Das Produkt Use-Case-Analyse Komponentenarchitektur Abhängigkeitsmanagement Fazit Das fehlende Kapitel Package by Layer Package by Feature, Ports and Adapters Package by Component Der Teufel steckt in den Implementierungsdetails Organisation vs. Kapselung Andere Entkopplungsmodi Fazit: Der fehlende Ratschlag 309 A Architekturarchäologie 311 A.l Das Buchhaltungssystem für die Gewerkschaft 312 A.2 Zurechtschneiden mit dem Laser 317 A.3 Monitoring von Aluminiumspritzguss 321 A.4 4-TEL 322 A.4.1 Service Area Computer 326 A.4.2 Ermittlung des Wartungsbedarfs 327 A.4.3 Architektur 327 A.4.4 Die große Neugestaltung 329 A.4.5 Europa 330 A.4.6 SAC: Fazit 330 A.5 Die Programmiersprache C 331 A.5.1 C 332 A.6 BOSS

10 unter Inhaltsverzeichnis A.7 Projekt CCU 333 A.7.1 Denkfalle: Die Planung 334 A.8 DLU/DRU 335 A.8.1 Architektur 336 A.9 VRS 337 A.9.1 Der Name 338 A.9.2 Architektur 338 A.9.3 VRS: Fazit 339 A.10 Der Elektronische Rezeptionist 340 A.10.1 Der Untergang des ER 341 A.ll Craft Dispatch System 342 A.12 Clear Communications 344 A.12.1 Die Gegebenheiten 345 A.12.2 UncleBob 346 A.12.3 Das Telefongespräch 346 A.13 ROSE 347 A.13.1 Fortsetzung der Debatten 348 A anderem Namen 348 A.14 Prüfung zum eingetragenen Architekten 349 A.15 Fazit 352 B Nachwort 353 Stichwortverzeichnis 357