
Clean Architecture
Description
Alles über E-Books | Antworten auf Fragen rund um E-Books, Kopierschutz und Dateiformate finden Sie in unserem Info- & Hilfebereich.
- Praktische Lösungen für den Aufbau von Softwarearchitekturen von dem legendären Softwareentwickler Robert C. Martin (»Uncle Bob«)
- Allgemeingültige Regeln für die Verbesserung der Produktivität in 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
Wirklich gute Software zu entwickeln, ist ein schwieriges Unterfangen und eine große Herausforderung. Aber wenn Software in der richtigen Art und Weise entwickelt wird, erfordert die Erstellung und Instandhaltung nur wenige Ressourcen, Modifikationen und Anpassungen lassen sich schnell und einfach umsetzen und Mängel und Fehler treten nur hin und wieder in Erscheinung. Der Entwicklungsaufwand ist minimal, und das bei maximaler Funktionalität und Flexibilität.
Was hier utopisch klingt, hat Robert C. Martin schon selbst erlebt und weiß deshalb, dass es so funktionieren kann.
Als Entwickler können Sie Ihre Produktivität über die Lebenszeit eines jeden Softwaresystems dramatisch verbessern, indem Sie allgemeingültige Grundsätze für die Entwicklung professioneller Softwarearchitektur anwenden. In diesem Buch verrät Ihnen der legendäre Softwareentwickler diese maßgeblichen Prinzipien und zeigt Ihnen, wie Sie diese erfolgreich und effektiv anwenden.
Basierend auf seiner mehr als 50-jährigen Berufserfahrung mit Softwareumgebungen jeder erdenklichen Art demonstriert Robert C. Martin in diesem Buch auf eindrucksvolle Weise, welche Entscheidungen Sie im Entwicklungsprozess treffen sollten und warum diese für Ihren Erfolg ausschlaggebend sind. Wie man es von »Uncle Bob« kennt, enthält dieses Buch zahlreiche unmittelbar anwendbare und in sich schlüssige Lösungen für die Herausforderungen, mit denen Sie im Berufsleben konfrontiert sein werden - jenen, die über Gedeih und Verderb Ihrer Projekte entscheiden.
In diesem Buch lernen Sie:
- Architektonische Zielsetzungen der Softwareentwicklung richtig abstecken und die dafür notwendigen Kerndisziplinen und -praktiken planvoll einsetzen
- Die grundlegenden Prinzipien des Softwaredesigns für den Umgang mit Funktionalität, Komponententrennung und Datenmanagement meistern
- Den Entwicklungsprozess optimieren durch die zielgerichtete Anwendung von Programmierparadigmen und die klare Definition der Handlungsspielräume der Softwareentwickler
- Wichtige systemrelevante Programmbestandteile von bloßen »Details« unterscheiden
- Optimale, hochschichtige Strukturen für Web, Datenbank, Fat Client, Konsole und eingebettete Anwendungen implementieren
- Angemessene Grenzen und Layer definieren und die Komponenten und Services in Ihrem System organisieren
- Faktoren für das Scheitern von Softwaredesigns und -architekturen erkennen und diese Fehler vermeiden
Clean Architecture ist für jeden gegenwärtigen oder angehenden Softwarearchitekten, Systemanalysten, Systemdesigner und Softwaremanager eine Pflichtlektüre - ebenso wie für jeden Programmierer, der die Softwaredesigns anderer Entwickler ausführen muss.
Reviews / Votes
»Indem [Martin R. C.] maßgebliche Prinzipien erörtert und aufzeigt, wie diese erfolgreich und effektiv anzuwenden sind, hat er einen Leitfaden geschaffen, von dem auch Hobbyprogrammierer erheblich profitieren können.« (Funkamateur, 07/2018)
More details
Other editions
Additional editions

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