Martin Clean Architecture

Das Praxis-Handbuch für professionelles Softwaredesign.Regeln und Paradigmen für effiziente Softwarestrukturierung.
1. Auflage 2018
ISBN: 978-3-95845-725-6
Verlag: mitp Verlags GmbH & Co.KG
Format: PDF
Kopierschutz: 0 - No protection

E-Book, Deutsch, 377 Seiten

Reihe: mitp Professional

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 LebenszyklusWie Softwareentwickler wesentliche Prinzipien des Softwaredesigns meistern, warum Softwarearchitekturen häufig scheitern und wie man solche Fehlschläge verhindern kannWirklich 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 einsetzenDie grundlegenden Prinzipien des Softwaredesigns für den Umgang mit Funktionalität, Komponententrennung und Datenmanagement meisternDen Entwicklungsprozess optimieren durch die zielgerichtete Anwendung von Programmierparadigmen und die klare Definition der Handlungsspielräume der SoftwareentwicklerWichtige systemrelevante Programmbestandteile von bloßen »Details« unterscheidenOptimale, hochschichtige Strukturen für Web, Datenbank, Fat Client, Konsole und eingebettete Anwendungen implementierenAngemessene Grenzen und Layer definieren und die Komponenten und Services in Ihrem System organisierenFaktoren für das Scheitern von Softwaredesigns und -architekturen erkennen und diese Fehler vermeidenClean 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.

Zielgruppe

Softwareentwickler und -architekten

Autoren/Hrsg.

Martin, Robert C.

Inhaltsverzeichnis

1;Cover;1
2;Titel;4
3;Impressum;5
4;Inhaltsverzeichnis;6
5;Vorwort;16
6;Einleitung;20
7;Über den Autor;24
8;Danksagung;25
9;Teil I: Einführung;26
9.1;Kapitel 1: Was bedeuten »Design« und »Architektur«?;30
9.1.1;1.1 Das Ziel?;31
9.1.2;1.2 Fallstudie;32
9.1.2.1;1.2.1 Die Signatur des Chaos;33
9.1.2.2;1.2.2 Die Perspektive der Unternehmensleitung;34
9.1.2.3;1.2.3 Was ist schiefgelaufen?;35
9.1.3;1.3 Fazit;38
9.2;Kapitel 2: Die Geschichte zweier Werte;40
9.2.1;2.1 Verhalten;40
9.2.2;2.2 Architektur;41
9.2.3;2.3 Der größere Wert;42
9.2.4;2.4 Das Eisenhower-Prinzip;43
9.2.5;2.5 Der Kampf für die Architektur;44
10;Teil II: Die ersten Bausteine setzen: Programmierparadigmen;46
10.1;Kapitel 3: Die Paradigmen;48
10.1.1;3.1 Strukturierte Programmierung;48
10.1.2;3.2 Objektorientierte Programmierung;49
10.1.3;3.3 Funktionale Programmierung;49
10.1.4;3.4 Denkanstöße;50
10.1.5;3.5 Fazit;50
10.2;Kapitel 4: Strukturierte Programmierung;52
10.2.1;4.1 Die Beweisführung;53
10.2.2;4.2 Eine »schädliche« Proklamation;55
10.2.3;4.3 Funktionale Dekomposition;56
10.2.4;4.4 Keine formalen Beweise;56
10.2.5;4.5 Wissenschaft als Rettung;56
10.2.6;4.6 Tests;57
10.2.7;4.7 Fazit;58
10.3;Kapitel 5: Objektorientierte Programmierung;60
10.3.1;5.1 Datenkapselung?;61
10.3.2;5.2 Vererbung?;64
10.3.3;5.3 Polymorphie;66
10.3.3.1;5.3.1 Die Macht der Polymorphie;68
10.3.3.2;5.3.2 Abhängigkeitsumkehr;69
10.3.4;5.4 Fazit;72
10.4;Kapitel 6: Funktionale Programmierung;74
10.4.1;6.1 Quadrierung von Integern;75
10.4.2;6.2 Unveränderbarkeit und Architektur;76
10.4.3;6.3 Unterteilung der Veränderbarkeit;77
10.4.4;6.4 Event Sourcing;78
10.4.5;6.5 Fazit;80
11;Teil III: Designprinzipien;82
11.1;Kapitel 7: SRP: Das Single-Responsibility-Prinzip;86
11.1.1;7.1 Symptom 1: Versehentliche Duplizierung;87
11.1.2;7.2 Symptom 2: Merges;89
11.1.3;7.3 Lösungen;90
11.1.4;7.4 Fazit;91
11.2;Kapitel 8: OCP: Das Open-Closed-Prinzip;92
11.2.1;8.1 Ein Gedankenexperiment;93
11.2.2;8.2 Richtungssteuerung;96
11.2.3;8.3 Information Hiding;96
11.2.4;8.4 Fazit;97
11.3;Kapitel 9: LSP: Das Liskov’sche Substitutionsprinzip;98
11.3.1;9.1 Gesteuerte Nutzung der Vererbung;99
11.3.2;9.2 Das Quadrat-Rechteck-Problem;99
11.3.3;9.3 Das LSP und die Softwarearchitektur;100
11.3.4;9.4 Beispiel für einen Verstoß gegen das LSP;100
11.3.5;9.5 Fazit;102
11.4;Kapitel 10: ISP: Das Interface-Segregation-Prinzip;104
11.4.1;10.1 Das ISP und die Programmiersprachen;105
11.4.2;10.2 Das ISP und die Softwarearchitektur;106
11.4.3;10.3 Fazit;106
11.5;Kapitel 11: DIP: Das Dependency-Inversion-Prinzip;108
11.5.1;11.1 Stabile Abstraktionen;109
11.5.2;11.2 Factories;110
11.5.3;11.3 Konkrete Komponenten;111
11.5.4;11.4 Fazit;111
12;Teil IV: Komponentenprinzipien;112
12.1;Kapitel 12: Komponenten;114
12.1.1;12.1 Eine kurze Historie der Komponenten;115
12.1.2;12.2 Relokatierbarkeit;117
12.1.3;12.3 Linker;118
12.1.4;12.4 Fazit;120
12.2;Kapitel 13: Komponentenkohäsion;122
12.2.1;13.1 REP: Das Reuse-Release-Equivalence-Prinzip;122
12.2.2;13.2 CCP: Das Common-Closure-Prinzip;124
12.2.2.1;13.2.1 Ähnlichkeiten mit dem SRP;125
12.2.3;13.3 CRP: Das Common-Reuse-Prinzip;125
12.2.3.1;13.3.1 Relation zum ISP;126
12.2.4;13.4 Das Spannungsdiagramm für die Komponentenkohäsion;126
12.2.5;13.5 Fazit;128
12.3;Kapitel 14: Komponentenkopplung;130
12.3.1;14.1 ADP: Das Acyclic-Dependencies-Prinzip;130
12.3.1.1;14.1.1 Der wöchentliche Build;131
12.3.1.2;14.1.2 Abhängigkeitszyklen abschaffen;132
12.3.1.3;14.1.3 Auswirkung eines Zyklus in einem Komponentenabhängigkeitsgraphen;134
12.3.1.4;14.1.4 Den Zyklus durchbrechen;135
12.3.1.5;14.1.5 Jitters (Fluktuationen);136
12.3.2;14.2 Top-down-Design;137
12.3.3;14.3 SDP: Das Stable-Dependencies-Prinzip;138
12.3.3.1;14.3.1 Stabilität;138
12.3.3.2;14.3.2 Stabilitätsmetriken;140
12.3.3.3;14.3.3 Nicht alle Komponenten sollten stabil sein;142
12.3.3.4;14.3.4 Abstrakte Komponenten;144
12.3.4;14.4 SAP: Das Stable-Abstractions-Prinzip;144
12.3.4.1;14.4.1 Wo werden die übergeordneten Richtlinien hinterlegt?;144
12.3.4.2;14.4.2 Einführung in das SAP (Stable-Abstractions-Prinzip);144
12.3.4.3;14.4.3 Bemessung der Abstraktion;145
12.3.4.4;14.4.4 Die Hauptreihe;145
12.3.4.5;14.4.5 Die »Zone of Pain«;146
12.3.4.6;14.4.6 Die »Zone of Uselessness«;147
12.3.4.7;14.4.7 Die Ausschlusszonen vermeiden;148
12.3.4.8;14.4.8 Abstand von der Hauptreihe;148
12.3.5;14.5 Fazit;150
13;Teil V: Softwarearchitektur;152
13.1;Kapitel 15: Was ist Softwarearchitektur?;154
13.1.1;15.1 Entwicklung;156
13.1.2;15.2 Deployment;156
13.1.3;15.3 Betrieb;157
13.1.4;15.4 Instandhaltung;158
13.1.5;15.5 Optionen offenhalten;158
13.1.6;15.6 Geräteunabhängigkeit;160
13.1.7;15.7 Junk Mail;162
13.1.8;15.8 Physische Adressierung;163
13.1.9;15.9 Fazit;164
13.2;Kapitel 16: Unabhängigkeit;166
13.2.1;16.1 Use Cases;166
13.2.2;16.2 Betrieb;167
13.2.3;16.3 Entwicklung;168
13.2.4;16.4 Deployment;168
13.2.5;16.5 Optionen offenhalten;169
13.2.6;16.6 Layer entkoppeln;169
13.2.7;16.7 Use Cases entkoppeln;170
13.2.8;16.8 Entkopplungsmodi;171
13.2.9;16.9 Unabhängige Entwickelbarkeit;172
13.2.10;16.10 Unabhängige Deploybarkeit;172
13.2.11;16.11 Duplizierung;172
13.2.12;16.12 Entkopplungsmodi (zum Zweiten);173
13.2.12.1;16.12.1 Welcher Modus ist am besten geeignet?;174
13.2.13;16.13 Fazit;175
13.3;Kapitel 17: Grenzen: Linien ziehen;176
13.3.1;17.1 Ein paar traurige Geschichten;177
13.3.2;17.2 FitNesse;180
13.3.3;17.3 Welche Grenzen sollten Sie ziehen – und wann?;182
13.3.4;17.4 Wie verhält es sich mit der Ein- und Ausgabe?;185
13.3.5;17.5 Plug-in-Architektur;186
13.3.6;17.6 Das Plug-in-Argument;187
13.3.7;17.7 Fazit;188
13.4;Kapitel 18: Anatomie der Grenzen;190
13.4.1;18.1 Grenzüberschreitungen;190
13.4.2;18.2 Der gefürchtete Monolith;191
13.4.3;18.3 Deployment-Komponenten;193
13.4.4;18.4 Threads;193
13.4.5;18.5 Lokale Prozesse;194
13.4.6;18.6 Services;194
13.4.7;18.7 Fazit;195
13.5;Kapitel 19: Richtlinien und Ebenen;196
13.5.1;19.1 Ebene;197
13.5.2;19.2 Fazit;200
13.6;Kapitel 20: Geschäftsregeln;202
13.6.1;20.1 Entitäten;203
13.6.2;20.2 Use Cases;204
13.6.3;20.3 Request-and-Response-Modelle;206
13.6.4;20.4 Fazit;207
13.7;Kapitel 21: Die schreiende Softwarearchitektur;208
13.7.1;21.1 Das Thema einer Architektur;209
13.7.2;21.2 Der Zweck einer Softwarearchitektur;209
13.7.3;21.3 Aber was ist mit dem Web?;210
13.7.4;21.4 Frameworks sind Tools, keine Lebenseinstellung;210
13.7.5;21.5 Testfähige Architekturen;211
13.7.6;21.6 Fazit;211
13.8;Kapitel 22: Die saubere Architektur;212
13.8.1;22.1 Die Abhängigkeitsregel (Dependency Rule);214
13.8.1.1;22.1.1 Entitäten;214
13.8.1.2;22.1.2 Use Cases;214
13.8.1.3;22.1.3 Schnittstellenadapter;215
13.8.1.4;22.1.4 Frameworks und Treiber;215
13.8.1.5;22.1.5 Nur vier Kreise?;216
13.8.1.6;22.1.6 Grenzen überschreiten;216
13.8.1.7;22.1.7 Welche Daten überqueren die Grenzlinien?;217
13.8.2;22.2 Ein typisches Beispiel;217
13.8.3;22.3 Fazit;218
13.9;Kapitel 23: Presenters und »Humble Objects«;220
13.9.1;23.1 Das Pattern »Humble Object«;220
13.9.2;23.2 Presenters und Views;221
13.9.3;23.3 Das Testen und die Softwarearchitektur;222
13.9.4;23.4 Datenbank-Gateways;222
13.9.5;23.5 Data Mappers;222
13.9.6;23.6 Service Listeners;223
13.9.7;23.7 Fazit;223
13.10;Kapitel 24: Partielle Grenzen;224
13.10.1;24.1 Den letzten Schritt weglassen;225
13.10.2;24.2 Eindimensionale Grenzen;225
13.10.3;24.3 Fassaden;226
13.10.4;24.4 Fazit;227
13.11;Kapitel 25: Layer und Grenzen;228
13.11.1;25.1 Hunt the Wumpus;229
13.11.2;25.2 Saubere Architektur?;230
13.11.3;25.3 Datenstromüberschreitungen;232
13.11.4;25.4 Datenströme teilen;233
13.11.5;25.5 Fazit;235
13.12;Kapitel 26: Die Komponente Main;236
13.12.1;26.1 Das ultimative Detail;236
13.12.2;26.2 Fazit;240
13.13;Kapitel 27: Services – große und kleine;242
13.13.1;27.1 Servicearchitektur?;242
13.13.2;27.2 Vorteile der Services?;243
13.13.2.1;27.2.1 Denkfalle: Entkopplung;243
13.13.2.2;27.2.2 Denkfalle: Unabhängige Entwickel- und Deploybarkeit;244
13.13.3;27.3 Das Kätzchen-Problem;244
13.13.4;27.4 Objekte als Rettung;246
13.13.5;27.5 Komponentenbasierte Services;248
13.13.6;27.6 Cross-Cutting Concerns;249
13.13.7;27.7 Fazit;249
13.14;Kapitel 28: Die Testgrenze;250
13.14.1;28.1 Tests als Systemkomponenten;250
13.14.2;28.2 Design für Testfähigkeit;251
13.14.3;28.3 Die Test-API;252
13.14.3.1;28.3.1 Strukturelle Kopplung;252
13.14.3.2;28.3.2 Sicherheit;253
13.14.4;28.4 Fazit;253
13.15;Kapitel 29: Saubere eingebettete Architektur;254
13.15.1;29.1 App-Eignungstest;257
13.15.2;29.2 Der Flaschenhals der Zielhardware;260
13.15.2.1;29.2.1 Eine saubere eingebettete Architektur ist eine testfähige eingebettete Architektur;261
13.15.2.2;29.2.2 Offenbaren Sie dem HAL-User keine Hardwaredetails;264
13.15.3;29.3 Fazit;270
14;Teil VI: Details;272
14.1;Kapitel 30: Die Datenbank ist ein Detail;274
14.1.1;30.1 Relationale Datenbanken;275
14.1.2;30.2 Warum sind Datenbanksysteme so weit verbreitet?;275
14.1.3;30.3 Was wäre, wenn es keine Festplatten gäbe?;276
14.1.4;30.4 Details;277
14.1.5;30.5 Und was ist mit der Performance?;277
14.1.6;30.6 Anekdote;278
14.1.7;30.7 Fazit;279
14.2;Kapitel 31: Das Web ist ein Detail;280
14.2.1;31.1 Der immerwährende Pendelausschlag;281
14.2.2;31.2 Quintessenz;282
14.2.3;31.3 Fazit;283
14.3;Kapitel 32: Ein Framework ist ein Detail;284
14.3.1;32.1 Framework-Autoren;285
14.3.2;32.2 Asymmetrische Ehe;285
14.3.3;32.3 Die Risiken;286
14.3.4;32.4 Die Lösung;286
14.3.5;32.5 Hiermit erkläre ich euch zu ...;287
14.3.6;32.6 Fazit;287
14.4;Kapitel 33: Fallstudie: Software für den Verkauf von Videos;288
14.4.1;33.1 Das Produkt;288
14.4.2;33.2 Use-Case-Analyse;289
14.4.3;33.3 Komponentenarchitektur;290
14.4.4;33.4 Abhängigkeitsmanagement;292
14.4.5;33.5 Fazit;292
14.5;Kapitel 34: Das fehlende Kapitel;294
14.5.1;34.1 Package by Layer;295
14.5.2;34.2 Package by Feature;296
14.5.3;34.3 Ports and Adapters;298
14.5.4;34.4 Package by Component;300
14.5.5;34.5 Der Teufel steckt in den Implementierungsdetails;305
14.5.6;34.6 Organisation vs. Kapselung;306
14.5.7;34.7 Andere Entkopplungsmodi;309
14.5.8;34.8 Fazit: Der fehlende Ratschlag;310
15;Anhang A: Architekturarchäologie;312
15.1;A.1 Das Buchhaltungssystem für die Gewerkschaft;313
15.2;A.2 Zurechtschneiden mit dem Laser;318
15.3;A.3 Monitoring von Aluminiumspritzguss;322
15.4;A.4 4-TEL;323
15.4.1;A.4.1 Service Area Computer;327
15.4.2;A.4.2 Ermittlung des Wartungsbedarfs;328
15.4.3;A.4.3 Architektur;328
15.4.4;A.4.4 Die große Neugestaltung;330
15.4.5;A.4.5 Europa;331
15.4.6;A.4.6 SAC: Fazit;331
15.5;A.5 Die Programmiersprache C;332
15.5.1;A.5.1 C;333
15.6;A.6 BOSS;333
15.7;A.7 Projekt CCU;334
15.7.1;A.7.1 Denkfalle: Die Planung;335
15.8;A.8 DLU/DRU;336
15.8.1;A.8.1 Architektur;337
15.9;A.9 VRS;338
15.9.1;A.9.1 Der Name;339
15.9.2;A.9.2 Architektur;339
15.9.3;A.9.3 VRS: Fazit;340
15.10;A.10 Der Elektronische Rezeptionist;341
15.10.1;A.10.1 Der Untergang des ER;342
15.11;A.11 Craft Dispatch System;343
15.12;A.12 Clear Communications;345
15.12.1;A.12.1 Die Gegebenheiten;346
15.12.2;A.12.2 Uncle Bob;347
15.12.3;A.12.3 Das Telefongespräch;347
15.13;A.13 ROSE;348
15.13.1;A.13.1 Fortsetzung der Debatten ...;349
15.13.2;A.13.2 ... unter anderem Namen;349
15.14;A.14 Prüfung zum eingetragenen Architekten;350
15.15;A.15 Fazit;353
16;Anhang B: Nachwort;354
17;Stichwortverzeichnis;358

Über Autor(innen)

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.