O'Reilly logo

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

PR: Clean Architecture - Das Praxis-Handbuch für gutes Softwaredesign

PR: Clean Architecture - Das Praxis-Handbuch für gutes Softwaredesign

by Robert C. Martin
Publisher: mitp Verlag
Release Date: February 2018
ISBN: 9783958457263
View table of contents
Start reading

Book Description

Das Praxis-Handbuch für gutes Softwaredesign

  • Praktische Lösungen für die Ausgestaltung guter Softwarearchitekturen von dem legendären Softwareexperten Robert C. Martin
  • Allgemeingültige Regeln für die Verbesserung der Produktivität der Softwareentwicklung über den gesamten Lebenszyklus
  • Wie Softwareentwickler wesentliche Prinzipien des Softwaredesigns meistern, warum Softwarearchitekturen häufig scheitern und wie man solche Fehlschläge verhindern kann

Durch die Anwendung allgemeingültiger Regeln der Softwarearchitektur können Sie die Produktivität der Softwareentwicklung über gesamten Lebenszyklus eines beliebigen Softwaresystems enorm verbessern. Nach seinen Bestseller-Erfolgen Clean Code und The Clean Coder blickt der legendäre amerikanische Softwareexperte Robert C. Martin (»Uncle Bob«) in seinem jüngsten Werk hinter die Kulissen dieser Regeln und bietet Ihnen wertvolle Hilfestellung für deren Umsetzung in der Praxis.

Dabei werden in Clean Architecture jedoch nicht bloß die verschiedenen zur Verfügung stehenden Möglichkeiten vorgestellt. Darüber hinaus lässt Sie Martin auch an seiner mehr als 50-jährigen professionellen Erfahrung mit Softwareumgebungen jeder erdenklichen Art teilhaben, um Ihnen aufzuzeigen, welche wichtigen Entscheidungen Sie treffen müssen und warum diese für Ihren Erfolg eine ausschlaggebende Rolle spielen. Wie man es von »Uncle Bob« erwarten kann, beschreibt auch dieses Buch geradlinige, zielführende Lösungen für die realen Herausforderungen, mit denen Sie sich konfrontiert sehen werden – eben genau diejenigen, die für den Erfolg oder Misserfolg Ihrer Projekte maßgeblich sind.

Sie erfahren,

  • was Softwarearchitekten erreichen müssen – und welche Kerndisziplinen und -praktiken dafür erforderlich sind,
  • wie Sie die wesentlichen Prinzipien des Softwaredesigns in Bezug auf die Funktionalität, die Komponententrennung und das Datenmanagement meistern,
  • inwieweit Programmierparadigmen die Arbeit der Softwareentwickler einer Disziplin unterwerfen, die ihre Handlungsspielräume einschränkt,
  • welche architektonischen Aspekte von entscheidender Bedeutung und welche eher unwesentliche »Details« sind,
  • wie Sie optimale übergeordnete Strukturen für das Web, Datenbanken, Fat Clients, Konsolen und eingebettete Anwendungen implementieren,
  • wie Sie geeignete Grenzen und Layer definieren sowie Komponenten und Services organisieren,
  • warum Softwaredesigns und -architekturen scheitern und wie man solchen Fehlschlägen vorbeugen (oder auch beheben) kann.

Clean Architecture ist eine Pflichtlektüre für alle aktiven und angehenden Softwarearchitekten, Systemanalytiker, Systementwickler und Softwaremanager – und für jeden Programmierer, der die Designs eines anderen ausführen muss.


Über den Autor

Robert C. Martin (»Uncle Bob«) ist bereits seit 1970 als Programmierer tätig. Neben seiner Beraterfirma Uncle Bob Consulting, LLC gründete er gemeinsam mit seinem Sohn Micah Martin auch das Unternehmen The Clean Coders, LLC. Er hat zahlreiche Artikel in verschiedenen Zeitschriften veröffentlicht und hält regelmäßig Vorträge auf internationalen Konferenzen.

Table of Contents

  1. Impressum
  2. Vorwort
  3. Einleitung
  4. Über den Autor
  5. Danksagung
  6. Teil I: Einführung
  7. Kapitel 1: Was bedeuten »Design« und »Architektur«?‌
    1. 1.1 Das Ziel‌?
    2. 1.2 Fallstudie
      1. 1.2.1 Die Signatur des Chaos‌‌
      2. 1.2.2 Die Perspektive der Unternehmensleitung
      3. 1.2.3 Was ist schiefgelaufen?
    3. 1.3 Fazit‌
  8. Kapitel 2: Die Geschichte zweier Werte‌
    1. 2.1 Verhalten‌
    2. 2.2 Architektur‌‌
    3. 2.3 Der größere Wert
    4. 2.4 Das Eisenhower-Prinzip‌‌‌‌
    5. 2.5 Der Kampf für die Architektur‌‌‌‌
  9. Teil II: Die ersten Bausteine setzen: Programmierparadigmen‌‌
  10. Kapitel 3: Die Paradigmen‌
    1. 3.1 Strukturierte Programmierung‌‌
    2. 3.2 Objektorientierte Programmierung‌
    3. 3.3 Funktionale Programmierung‌
    4. 3.4 Denkanstöße
    5. 3.5 Fazit‌
  11. Kapitel 4: Strukturierte Programmierung‌
    1. 4.1 Die Beweisführung‌‌
    2. 4.2 Eine »schädliche« Proklamation‌‌
    3. 4.3 Funktionale Dekomposition‌‌
    4. 4.4 Keine formalen Beweise
    5. 4.5 Wissenschaft‌ als Rettung
    6. 4.6 Tests‌‌
    7. 4.7 Fazit‌
  12. Kapitel 5: Objektorientierte Programmierung‌
    1. 5.1 Datenkapselung‌‌?
    2. 5.2 Vererbung‌‌?
    3. 5.3 Polymorphie‌‌
      1. 5.3.1 Die Macht der Polymorphie‌‌
      2. 5.3.2 Abhängigkeitsumkehr‌‌‌
    4. 5.4 Fazit‌
  13. Kapitel 6: Funktionale Programmierung‌
    1. 6.1 Quadrierung von Integern‌‌
    2. 6.2 Unveränderbarkeit‌‌ und Architektur‌
    3. 6.3 Unterteilung der Veränderbarkeit‌
    4. 6.4 Event Sourcing‌
    5. 6.5 Fazit‌
  14. Teil III: Designprinzipien‌
  15. Kapitel 7: SRP: Das Single-Responsibility-Prinzip‌
    1. 7.1 Symptom 1: Versehentliche Duplizierung‌‌‌
    2. 7.2 Symptom 2: Merges‌‌
    3. 7.3 Lösungen‌
    4. 7.4 Fazit‌
  16. Kapitel 8: OCP: Das Open-Closed-Prinzip‌
    1. 8.1 Ein Gedankenexperiment‌
    2. 8.2 Richtungssteuerung‌‌
    3. 8.3 Information Hiding‌‌‌
    4. 8.4 Fazit‌
  17. Kapitel 9: LSP: Das Liskov’sche Substitutionsprinzip‌
    1. 9.1 Gesteuerte Nutzung der Vererbung‌‌‌
    2. 9.2 Das Quadrat-Rechteck-Problem‌‌
    3. 9.3 Das LSP und die Softwarearchitektur‌‌
    4. 9.4 Beispiel für einen Verstoß gegen das LSP‌
    5. 9.5 Fazit‌
  18. Kapitel 10: ISP: Das Interface-Segregation-Prinzip‌
    1. 10.1 Das ISP und die Programmiersprachen‌‌
    2. 10.2 Das ISP und die Softwarearchitektur‌‌
    3. 10.3 Fazit‌
  19. Kapitel 11: DIP: Das Dependency-Inversion-Prinzip‌
    1. 11.1 Stabile Abstraktionen‌‌
    2. 11.2 Factories‌
    3. 11.3 Konkrete Komponenten‌‌‌
    4. 11.4 Fazit‌
  20. Teil IV: Komponentenprinzipien‌
  21. Kapitel 12: Komponenten‌
    1. 12.1 Eine kurze Historie der Komponenten‌
    2. 12.2 Relokatierbarkeit‌
    3. 12.3 Linker‌
    4. 12.4 Fazit‌
  22. Kapitel 13: Komponentenkohäsion‌
    1. 13.1 REP: Das Reuse-Release-Equivalence-Prinzip‌‌
    2. 13.2 CCP: Das Common-Closure-Prinzip‌‌
      1. 13.2.1 Ähnlichkeiten mit dem SRP‌
    3. 13.3 CRP: Das Common-Reuse-Prinzip‌‌
      1. 13.3.1 Relation zum ISP‌
    4. 13.4 Das Spannungsdiagramm für die Komponentenkohäsion‌
    5. 13.5 Fazit‌
  23. Kapitel 14: Komponentenkopplung‌‌‌
    1. 14.1 ADP: Das Acyclic-Dependencies-Prinzip‌‌
      1. 14.1.1 Der wöchentliche Build‌‌‌‌
      2. 14.1.2 Abhängigkeitszyklen abschaffen‌‌
      3. 14.1.3 Auswirkung eines Zyklus in einem Komponentenabhängigkeitsgraphen‌‌
      4. 14.1.4 Den Zyklus durchbrechen‌‌‌
      5. 14.1.5 Jitters (Fluktuationen)‌‌
    2. 14.2 Top-down-Design‌‌
    3. 14.3 SDP: Das Stable-Dependencies-Prinzip‌‌‌‌
      1. 14.3.1 Stabilität
      2. 14.3.2 Stabilitätsmetriken‌‌‌‌
      3. 14.3.3 Nicht alle Komponenten sollten stabil sein‌‌
      4. 14.3.4 Abstrakte Komponenten‌‌‌
    4. 14.4 SAP: Das Stable-Abstractions-Prinzip‌
      1. 14.4.1 Wo werden die übergeordneten Richtlinien hinterlegt?‌‌
      2. 14.4.2 Einführung in das SAP (Stable-Abstractions-Prinzip)‌‌
      3. 14.4.3 Bemessung der Abstraktion‌‌
      4. 14.4.4 Die Hauptreihe‌‌‌
      5. 14.4.5 Die »Zone of Pain‌«
      6. 14.4.6 Die »Zone of Uselessness‌‌«
      7. 14.4.7 Die Ausschlusszonen vermeiden‌‌‌
      8. 14.4.8 Abstand von der Hauptreihe‌‌‌
    5. 14.5 Fazit‌‌
  24. Teil V: Softwarearchitektur
  25. Kapitel 15: Was ist Softwarearchitektur?
    1. 15.1 Entwicklung‌‌
    2. 15.2 Deployment‌‌
    3. 15.3 Betrieb‌
    4. 15.4 Instandhaltung‌
    5. 15.5 Optionen offenhalten‌
    6. 15.6 Geräteunabhängigkeit‌‌‌
    7. 15.7 Junk Mail‌‌‌
    8. 15.8 Physische Adressierung‌‌‌
    9. 15.9 Fazit‌
  26. Kapitel 16: Unabhängigkeit‌‌
    1. 16.1 Use Cases‌‌‌
    2. 16.2 Betrieb‌‌
    3. 16.3 Entwicklung‌‌
    4. 16.4 Deployment‌‌
    5. 16.5 Optionen offenhalten‌‌‌
    6. 16.6 Layer entkoppeln‌‌‌
    7. 16.7 Use Cases entkoppeln‌‌‌
    8. 16.8 Entkopplungsmodi‌‌
    9. 16.9 Unabhängige Entwickelbarkeit‌‌‌‌‌
    10. 16.10 Unabhängige Deploybarkeit‌‌‌
    11. 16.11 Duplizierung‌‌‌
    12. 16.12 Entkopplungsmodi‌‌ (zum Zweiten)
      1. 16.12.1 Welcher Modus ist am besten geeignet?
    13. 16.13 Fazit‌
  27. Kapitel 17: Grenzen‌: Linien ziehen
    1. 17.1 Ein paar traurige Geschichten‌
    2. 17.2 FitNesse‌
    3. 17.3 Welche Grenzen sollten Sie ziehen – und wann‌?
    4. 17.4 Wie verhält es sich mit der Ein- und Ausgabe‌?
    5. 17.5 Plug-in-Architektur‌‌‌
    6. 17.6 Das Plug-in-Argument‌
    7. 17.7 Fazit‌
  28. Kapitel 18: Anatomie der Grenzen‌
    1. 18.1 Grenzüberschreitungen‌
    2. 18.2 Der gefürchtete Monolith‌
    3. 18.3 Deployment-Komponenten‌‌
    4. 18.4 Threads‌
    5. 18.5 Lokale Prozesse‌‌
    6. 18.6 Services‌
    7. 18.7 Fazit‌
  29. Kapitel 19: Richtlinien‌ und Ebenen‌
    1. 19.1 Ebene
    2. 19.2 Fazit‌
  30. Kapitel 20: Geschäftsregeln‌
    1. 20.1 Entitäten‌‌‌
    2. 20.2 Use Cases‌‌
    3. 20.3 Request-and-Response-Modelle‌‌‌
    4. 20.4 Fazit‌
  31. Kapitel 21: Die schreiende Softwarearchitektur‌
    1. 21.1 Das Thema einer Architektur‌
    2. 21.2 Der Zweck einer Softwarearchitektur‌‌
    3. 21.3 Aber was ist mit dem Web‌‌?
    4. 21.4 Frameworks sind Tools, keine Lebenseinstellung‌‌
    5. 21.5 Testfähige Architekturen‌‌
    6. 21.6 Fazit‌
  32. Kapitel 22: Die saubere Architektur‌
    1. 22.1 Die Abhängigkeitsregel‌‌‌ (Dependency Rule)
      1. 22.1.1 Entitäten‌‌
      2. 22.1.2 Use Cases‌‌
      3. 22.1.3 Schnittstellenadapter‌‌
      4. 22.1.4 Frameworks und Treiber‌‌‌‌
      5. 22.1.5 Nur vier Kreise?
      6. 22.1.6 Grenzen überschreiten‌‌‌
      7. 22.1.7 Welche Daten überqueren die Grenzlinien‌‌‌?
    2. 22.2 Ein typisches Beispiel‌
    3. 22.3 Fazit‌
  33. Kapitel 23: Presenters und »Humble Objects«‌‌
    1. 23.1 Das Pattern »Humble Object«
    2. 23.2 Presenters und Views‌‌‌‌
    3. 23.3 Das Testen und die Softwarearchitektur‌‌‌‌
    4. 23.4 Datenbank-Gateways‌‌‌‌
    5. 23.5 Data Mappers‌‌‌
    6. 23.6 Service Listeners‌‌
    7. 23.7 Fazit‌
  34. Kapitel 24: Partielle Grenzen‌‌
    1. 24.1 Den letzten Schritt weglassen‌
    2. 24.2 Eindimensionale Grenzen‌‌‌
    3. 24.3 Fassaden‌
    4. 24.4 Fazit‌
  35. Kapitel 25: Layer und Grenzen‌
    1. 25.1 Hunt the Wumpus
    2. 25.2 Saubere Architektur‌‌?
    3. 25.3 Datenstromüberschreitungen‌‌
    4. 25.4 Datenströme teilen‌‌‌‌
    5. 25.5 Fazit‌
  36. Kapitel 26: Die Komponente Main‌
    1. 26.1 Das ultimative Detail‌
    2. 26.2 Fazit‌
  37. Kapitel 27: Services‌ – große und kleine
    1. 27.1 Servicearchitektur‌?
    2. 27.2 Vorteile der Services‌?
      1. 27.2.1 Denkfalle: Entkopplung‌‌‌‌
      2. 27.2.2 Denkfalle: Unabhängige Entwickel- und Deploybarkeit‌‌‌
    3. 27.3 Das Kätzchen-Problem‌‌‌‌‌‌
    4. 27.4 Objekte als Rettung‌‌‌‌‌
    5. 27.5 Komponentenbasierte Services‌
    6. 27.6 Cross-Cutting Concerns
    7. 27.7 Fazit‌
  38. Kapitel 28: Die Testgrenze‌
    1. 28.1 Tests als Systemkomponenten‌‌
    2. 28.2 Design für Testfähigkeit‌‌‌
    3. 28.3 Die Test-API‌‌
      1. 28.3.1 Strukturelle Kopplung‌
      2. 28.3.2 Sicherheit
    4. 28.4 Fazit‌
  39. Kapitel 29: Saubere eingebettete Architektur‌
    1. 29.1 App-Eignungstest‌‌
    2. 29.2 Der Flaschenhals der Zielhardware‌‌
      1. 29.2.1 Eine saubere eingebettete Architektur ist eine testfähige eingebettete Architektur‌‌
      2. 29.2.2 Offenbaren Sie dem HAL-User keine Hardwaredetails‌‌‌
    3. 29.3 Fazit‌
  40. Teil VI: Details
  41. Kapitel 30: Die Datenbank ist ein Detail‌‌‌
    1. 30.1 Relationale Datenbanken‌
    2. 30.2 Warum sind Datenbanksysteme so weit verbreitet?‌‌
    3. 30.3 Was wäre, wenn es keine Festplatten gäbe?‌‌
    4. 30.4 Details‌
    5. 30.5 Und was ist mit der Performance‌‌?
    6. 30.6 Anekdote‌
    7. 30.7 Fazit‌
  42. Kapitel 31: Das Web ist ein Detail‌‌‌
    1. 31.1 Der immerwährende Pendelausschlag
    2. 31.2 Quintessenz
    3. 31.3 Fazit‌
  43. Kapitel 32: Ein Framework ist ein Detail‌‌‌
    1. 32.1 Framework-Autoren‌‌
    2. 32.2 Asymmetrische Ehe‌
    3. 32.3 Die Risiken‌‌
    4. 32.4 Die Lösung‌
    5. 32.5 Hiermit erkläre ich euch zu ...
    6. 32.6 Fazit‌
  44. Kapitel 33: Fallstudie: Software‌ für den Verkauf von Videos
    1. 33.1 Das Produkt‌‌
    2. 33.2 Use-Case-Analyse‌‌
    3. 33.3 Komponentenarchitektur‌‌
    4. 33.4 Abhängigkeitsmanagement‌‌‌‌
    5. 33.5 Fazit‌
  45. Kapitel 34: Das fehlende Kapitel‌
    1. 34.1 Package by Layer‌‌
    2. 34.2 Package by Feature‌‌
    3. 34.3 Ports and Adapters‌
    4. 34.4 Package by Component‌
    5. 34.5 Der Teufel steckt in den Implementierungsdetails‌
    6. 34.6 Organisation vs. Kapselung‌‌‌
    7. 34.7 Andere Entkopplungsmodi‌
    8. 34.8 Fazit: Der fehlende Ratschlag
  46. Anhang A: Architekturarchäologie
    1. A.1 Das Buchhaltungssystem für die Gewerkschaft
    2. A.2 Zurechtschneiden mit dem Laser
    3. A.3 Monitoring von Aluminiumspritzguss
    4. A.4 4-TEL
      1. A.4.1 Service Area Computer
      2. A.4.2 Ermittlung des Wartungsbedarfs
      3. A.4.3 Architektur
      4. A.4.4 Die große Neugestaltung
      5. A.4.5 Europa
      6. A.4.6 SAC: Fazit
    5. A.5 Die Programmiersprache C
      1. A.5.1 C
    6. A.6 BOSS
    7. A.7 Projekt CCU
      1. A.7.1 Denkfalle: Die Planung
    8. A.8 DLU/DRU
      1. A.8.1 Architektur
    9. A.9 VRS
      1. A.9.1 Der Name
      2. A.9.2 Architektur
      3. A.9.3 VRS: Fazit
    10. A.10 Der Elektronische Rezeptionist
      1. A.10.1 Der Untergang des ER
    11. A.11 Craft Dispatch System
    12. A.12 Clear Communications
      1. A.12.1 Die Gegebenheiten
      2. A.12.2 Uncle Bob
      3. A.12.3 Das Telefongespräch
    13. A.13 ROSE
      1. A.13.1 Fortsetzung der Debatten ...
      2. A.13.2 ... unter anderem Namen
    14. A.14 Prüfung zum eingetragenen Architekten
    15. A.15 Fazit
  47. Anhang B: Nachwort