Richards / Ford Handbuch moderner Softwarearchitektur

Architekturstile, Patterns und Best Practices
1. Auflage 2020
ISBN: 978-3-96010-429-2
Verlag: O'Reilly
Format: PDF
Kopierschutz: 1 - PDF Watermark

E-Book, Deutsch, 432 Seiten

Softwarearchitektur zeitgemäß und pragmatisch geplant

• Architektonische Muster: Das technische Fundament für viele architektonische Entscheidungen
• Komponenten: Identifizierung, Kopplung, Kohäsion, Partitionierung und Granularität
• Architekturstile wie Microkernel, SOA, Microservices u.v.m. und ihre architektonischen Eigenschaften
• Softwarearchitektur als Engineering-Disziplin: mit wiederhol- und messbaren Ergebnissen zu stabilen Architekturen

Mark Richards und Neal Ford - Praktiker mit Erfahrung aus erster Hand, die seit Jahren das Thema Softwarearchitektur unterrichten -, betrachten Softwarearchitektur vor dem Hintergrund der Entwicklungen, Innovationen und Herausforderungen des letzten Jahrzehnts. Sie konzentrieren sich auf Architekturprinzipien, die für alle Technologie-Stacks gelten.
Angehende und erfahrene Architekten finden in diesem Buch umfassende Informationen zu architektonischen Merkmalen und Architekturstilen, zur Bestimmung von Komponenten, zur Diagrammerstellung und Präsentation, zu evolutionärer Architektur und vielen weiteren Themen.
Die Autoren verstehen Softwarearchitektur als Engineering-Disziplin: mit wiederhol- und messbaren Ergebnissen und konkreten Kennzahlen für stabile Softwarearchitekturen.

Mark Richards ist ein erfahrener Softwarearchitekt, der sich mit Architektur, Design und Implementierung von Microservices-Architekturen, Event-getriebenen Architekturen und anderen verteilten Systemen beschäftigt. Neal Ford ist Direktor, Softwarearchitekt und Meme-Ritter bei ThoughtWorks, einem weltweit tätigen IT-Beratungsunternehmen mit dem Fokus auf Ende-zu-Ende-Sofwareentwicklung und -bereitstellung. Neal war außerdem Chief Technology Officer bei der DSW Group.

Autoren/Hrsg.

Richards, Mark

Ford, Neal

Inhaltsverzeichnis

1;Inhalt;6
2;Vorwort: Axiome infrage stellen;14
3;Kapitel 1: Einleitung;20
3.1;Softwarearchitektur definieren;22
3.2;Erwartungen an Architekten;26
3.2.1;Architekturentscheidungen treffen;27
3.2.2;Kontinuierliche Analyse der Architektur;28
3.2.3;Bei aktuellen Trends auf dem Laufenden bleiben;28
3.2.4;Sicherstellen, dass Entscheidungen eingehalten werden;29
3.2.5;Vielfältige Kenntnisse und Erfahrungen;29
3.2.6;Wissen in der Fachdomäne des Problems;30
3.2.7;Fähigkeiten im zwischenmenschlichen Umgang;30
3.2.8;Politik verstehen und sich in dieser Sqhäre bewegen können;31
3.3;Überschneidungen von Architektur und …;32
3.3.1;Engineering-Praktiken;33
3.3.2;Technischer Betrieb/DevOps;36
3.3.3;Prozess;37
3.3.4;Daten;38
3.4;Gesetze der Softwarearchitektur;38
4;Teil I: Grundlagen;40
4.1;Kapitel 2: Architektonisches Denken;42
4.1.1;Architektur und Design im Vergleich;43
4.1.2;Technische Breite;45
4.1.3;Vor- und Nachteile analysieren;49
4.1.4;Geschäftliche Faktoren verstehen;52
4.1.5;Die Balance zwischen Architektur und tatsächlichem Programmieren;53
4.2;Kapitel 3: Modularität;56
4.2.1;Definition;57
4.2.2;Modularität messen;59
4.2.2.1;Kohäsion;59
4.2.2.2;Kopplung;63
4.2.2.3;Abstraktheit, Instabilität und Entfernung von der Hauptsequenz;64
4.2.2.4;Entfernung von der Hauptsequenz;65
4.2.2.5;Konnaszenz;67
4.2.2.6;Kopplungs- und Konnaszenzmetriken vereinheitlichen;71
4.2.3;Von Modulen zu Komponenten;73
4.3;Kapitel 4: Definition architektonischer Eigenschaften;74
4.3.1;Architektonische Eigenschaften, eine (unvollständige) Liste;77
4.3.1.1;Betriebsrelevante architektonische Eigenschaften;77
4.3.1.2;Strukturelle architektonische Eigenschaften;78
4.3.1.3;Bereichsübergreifende architektonische Eigenschaften;79
4.3.2;Kompromisse und am wenigsten schlechte Architektur;83
4.4;Kapitel 5: Architektonische Eigenschaften ermitteln;86
4.4.1;Architektonische Eigenschaften aus domänenspezifischen Anforderungen ableiten;86
4.4.2;Architektonische Eigenschaften aus funktionalen Anforderungen ableiten;89
4.4.3;Fallstudie: Silicon Sandwiches;90
4.4.3.1;Explizite Eigenschaften;91
4.4.3.2;Implizite Eigenschaften;95
4.5;Kapitel 6: Messung und Governance von architektonischen Eigenschaften;98
4.5.1;Architektonische Eigenschaften messen;98
4.5.1.1;Betriebsrelevante Metriken;99
4.5.1.2;Strukturelle Metriken;100
4.5.1.3;Prozessbasierte Metriken;102
4.5.2;Governance und Fitnessfunktionen;103
4.5.2.1;Governance für architektonische Eigenschaften;103
4.5.2.2;Fitnessfunktionen;104
4.6;Kapitel 7: Anwendungsbereich architektonischer Eigenschaften;112
4.6.1;Kopplung und Konnaszenz;113
4.6.2;Architektonische Quanten und Granularität;113
4.6.2.1;Fallstudie: Going, Going, Gone (»Zum Ersten, zum Zweiten und zum Dritten«);116
4.7;Kapitel 8: Komponentenbasiertes Denken;122
4.7.1;Anwendungsbereiche für Komponenten;122
4.7.2;Die Rolle des Architekten;124
4.7.2.1;Architektonische Partitionierung;124
4.7.2.2;Fallstudie: Partitionierung für Silicon Sandwiches;128
4.7.3;Die Rolle des Entwicklers;131
4.7.4;Arbeitsablauf zur Ermittlung der Komponenten;131
4.7.4.1;Anfängliche Komponenten ermitteln;131
4.7.4.2;Anforderungen auf Komponenten abbilden;132
4.7.4.3;Rollen und Verantwortlichkeiten analysieren;132
4.7.4.4;Architektonische Eigenschaften analysieren;132
4.7.4.5;Komponenten restrukturieren;133
4.7.5;Komponentengranularität;133
4.7.6;Komponentendesign;133
4.7.6.1;Sinnvolle Komponentenaufteilung ermitteln;133
4.7.7;Fallstudie: Going, Going, Gone: Komponenten ermitteln;136
4.7.8;Rückblick auf das architektonische Quantum: Die Wahl zwischen monolithischen und verteilten Architekturen;139
5;Teil II: Architekturstile;142
5.1;Kapitel 9: Architekturstile;144
5.1.1;Grundmuster;144
5.1.1.1;Big Ball of Mud (Der »große Matschklumpen«);145
5.1.1.2;Eingliedrige Architektur;146
5.1.1.3;Client/Server;146
5.1.2;Monolithische und verteilte Architekturen;148
5.1.2.1;Irrtum Nr. 1: Das Netzwerk ist verlässlich;149
5.1.2.2;Irrtum Nr. 2: Die Latenz ist gleich null;149
5.1.2.3;Irrtum Nr. 3: Die Bandbreite ist unendlich;150
5.1.2.4;Irrtum Nr. 4: Das Netzwerk ist sicher;152
5.1.2.5;Irrtum Nr. 5: Die Topologie ändert sich nie;152
5.1.2.6;Irrtum Nr. 6: Es gibt nur einen Administrator;153
5.1.2.7;Irrtum Nr. 7: Die Transportkosten sind gleich null;154
5.1.2.8;Irrtum Nr. 8: Das Netzwerk ist homogen;154
5.1.2.9;Weitere Überlegungen zum verteilten Rechnen;155
5.2;Kapitel 10: Der schichtbasierte Architekturstil;158
5.2.1;Topologie;158
5.2.2;Voneinander isolierte Schichten;160
5.2.3;Schichten hinzufügen;162
5.2.4;Zusätzliche Überlegungen;163
5.2.5;Gründe für den schichtbasierten Architekturstil;164
5.2.6;Bewertung der architektonischen Eigenschaften;165
5.3;Kapitel 11: Pipeline-Architekturstil;168
5.3.1;Topologie;168
5.3.1.1;Pipes;169
5.3.1.2;Filter;169
5.3.2;Beispiel;170
5.3.3;Bewertung der architektonischen Eigenschaften;171
5.4;Kapitel 12: Microkernel-Architekturstil;174
5.4.1;Topologie;174
5.4.1.1;Kernsystem;175
5.4.1.2;Plug-in-Komponenten;178
5.4.2;Registry;181
5.4.3;Kontrakte;182
5.4.4;Beispiele und Anwendungsfälle;183
5.4.5;Bewertung der architektonischen Eigenschaften;184
5.5;Kapitel 13: Servicebasierter Architekturstil;186
5.5.1;Topologie;186
5.5.2;Topologische Varianten;187
5.5.3;Servicedesign und Granularität;190
5.5.4;Datenbank-Partitionierung;192
5.5.5;Beispielarchitektur;195
5.5.6;Bewertung der architektonischen Eigenschaften;196
5.5.7;Wann man diesen Architekturstil verwenden sollte;199
5.6;Kapitel 14: Eventbasierter Architekturstil;202
5.6.1;Topologie;203
5.6.2;Broker-Topologie;203
5.6.3;Mediator-Topologie;208
5.6.4;Asynchrone Fähigkeiten;219
5.6.5;Fehlerbehandlung;221
5.6.6;Datenverlust verhindern;224
5.6.7;Broadcast-Fähigkeiten;226
5.6.8;Request-Reply;227
5.6.9;Request- oder eventbasiert?;230
5.6.10;Hybride eventbasierte Architekturen;230
5.6.11;Bewertung der architektonischen Eigenschaften;231
5.7;Kapitel 15: »Space-based«-Architekturstil;234
5.7.1;Allgemeine Topologie;235
5.7.1.1;Verarbeitungseinheit;236
5.7.1.2;Virtualisierte Middleware;237
5.7.1.3;Data Pumps;242
5.7.1.4;Data Writer;244
5.7.1.5;Data Reader;245
5.7.2;Datenkollisionen;247
5.7.3;Cloudbasierte und On-Premises-Implementierungen im Vergleich;250
5.7.4;Repliziertes Caching im Vergleich mit verteiltem Caching;251
5.7.5;Überlegungen zu Near-Cache;254
5.7.6;Implementierungsbeispiele;255
5.7.6.1;System zum Verkauf von Veranstaltungstickets;255
5.7.6.2;Online-Auktionssysteme;256
5.7.7;Bewertung der architektonischen Eigenschaften;256
5.8;Kapitel 16: Orchestrierter serviceorientierter Architekturstil (SOA);260
5.8.1;Geschichte und Philosophie;260
5.8.2;Topologie;261
5.8.3;Taxonomie;261
5.8.3.1;Dienste für die Geschäftslogik;262
5.8.3.2;Unternehmensdienste;262
5.8.3.3;Applikationsdienste;262
5.8.3.4;Infrastrukturdienste;263
5.8.3.5;Orchestrierungs-Engine;263
5.8.3.6;Nachrichtenfluss;263
5.8.4;Wiederverwendbarkeit und Kopplung;264
5.8.5;Bewertung der architektonische Eigenschaften;266
5.9;Kapitel 17: Microservices-Architekturstil;270
5.9.1;Geschichte;270
5.9.2;Topologie;271
5.9.3;Verteilt;272
5.9.4;Bounded Context;272
5.9.4.1;Granularität;273
5.9.4.2;Datenisolation;274
5.9.5;API-Schicht;274
5.9.6;Betriebliche Wiederverwendung (Operational Reuse);275
5.9.7;Frontends;277
5.9.8;Kommunikation;279
5.9.8.1;Choreografie und Orchestrierung;280
5.9.8.2;Transaktionen und Sagas;284
5.9.9;Bewertung der architektonischen Eigenschaften;286
5.9.10;Weiterführende Referenzen;288
5.10;Kapitel 18: Den richtigen Architekturstil auswählen;290
5.10.1;Architekturstile als »Modeerscheinungen«;290
5.10.2;Entscheidungskriterien;292
5.10.3;Monolith-Fallstudie: Silicon Sandwiches;294
5.10.3.1;Modularer Monolith;294
5.10.3.2;Microkernel;296
5.10.4;Verteilte Architektur, Fallstudie: Going, Going, Gone;297
6;Teil III: Techniken und Soft Skills;302
6.1;Kapitel 19: Architekturentscheidungen;304
6.1.1;Antipatterns für Architekturentscheidungen;304
6.1.1.1;Antipattern: Covering your Assets;304
6.1.1.2;Antipattern: Groundhog Day;305
6.1.1.3;Antipattern: Email-Driven Architecture;306
6.1.2;Architektonisch wichtig;307
6.1.3;Architecture Decision Records (ADR);308
6.1.3.1;Grundstruktur;309
6.1.3.2;ADRs speichern;315
6.1.3.3;ADRs als Dokumentation;317
6.1.3.4;ADRs für Standards verwenden;317
6.1.3.5;Beispiel;318
6.2;Kapitel 20: Architektonische Risiken analysieren;320
6.2.1;Matrix zur Risikobewertung;320
6.2.2;Risikobewertung;321
6.2.3;Risk Storming;324
6.2.3.1;Identifizierung;326
6.2.3.2;Konsens;327
6.2.4;Risikoanalyse von Agile Stories;330
6.2.5;Risk-Storming-Beispiele;331
6.2.5.1;Verfügbarkeit;332
6.2.5.2;Elastizität;334
6.2.5.3;Sicherheit;336
6.3;Kapitel 21: Architektur in Diagrammen und Präsentationen visualisieren;338
6.3.1;Diagramme;339
6.3.1.1;Werkzeuge;339
6.3.1.2;Standards für Diagramme: UML, C4 und ArchiMate;341
6.3.1.3;Richtlinien für die Erstellung von Diagrammen;342
6.3.2;Präsentieren;344
6.3.2.1;Zeit manipulieren;345
6.3.2.2;Inkrementeller Aufbau;345
6.3.2.3;Infodecks im Vergleich mit Präsentationen;348
6.3.2.4;Folien sind nur die Hälfte des Vortrags;348
6.3.2.5;Unsichtbarkeit;348
6.4;Kapitel 22: Effektive Teams schaffen;350
6.4.1;Teams den richtigen Rahmen vorgeben;350
6.4.2;Architekten-Persönlichkeiten;351
6.4.2.1;Der Kontrollfreak;351
6.4.2.2;Der Sofa-Architekt;353
6.4.2.3;Der effektive Architekt;355
6.4.3;Wie viel Kontrolle?;355
6.4.4;Warnsignale des Teams;360
6.4.5;Checklisten einsetzen;362
6.4.5.1;Entwickler-Checkliste für die Codefertigstellung;365
6.4.5.2;Checkliste für Unit- und funktionales Testing;366
6.4.5.3;Software-Release-Checkliste;367
6.4.6;Orientierung bieten;367
6.4.7;Zusammenfassung;370
6.5;Kapitel 23: Verhandlungsgeschick und Führungsqualitäten;372
6.5.1;Verhandlung und Moderation;372
6.5.1.1;Mit geschäftlichen Entscheidungsträgern verhandeln;373
6.5.1.2;Mit anderen Architekten verhandeln;375
6.5.1.3;Mit Enwicklern verhandeln;376
6.5.2;Der Softwarearchitekt als Führungskraft;378
6.5.2.1;Die vier Ks der Architektur;378
6.5.2.2;Seien Sie pragmatisch, aber visionär;380
6.5.2.3;Teams mit gutem Beispiel vorangehen;382
6.5.3;Abstimmung mit dem Entwicklungsteam;386
6.5.4;Zusammenfassung;389
6.6;Kapitel 24: Eine berufliche Laufbahn entwickeln;390
6.6.1;Die 20-Minuten-Regel;390
6.6.2;Ein persönliches Radar entwickeln;392
6.6.2.1;Das ThoughtWorks Technology Radar;392
6.6.2.2;Open-Source-Visualisierungen;396
6.6.3;Soziale Medien verwenden;396
6.6.4;Rat zum Abschied;397
7;Anhang A: Fragen zur Selbstbeurteilung;400
8;Index;410

Über Autor(innen)

Mark Richards ist ein erfahrener Softwarearchitekt, der sich mit Architektur, Design und Implementierung von Microservices-Architekturen, Event-getriebenen Architekturen und anderen verteilten Systemen beschäftigt.
Neal Ford ist Direktor, Softwarearchitekt und Meme-Ritter bei ThoughtWorks, einem weltweit tätigen IT-Beratungsunternehmen mit dem Fokus auf Ende-zu-Ende-Sofwareentwicklung und -bereitstellung. Neal war außerdem Chief Technology Officer bei der DSW Group.