Inhaltsverzeichnis · Inhaltsverzeichnis 10 22 Die saubere Architektur. . . . . . . . . . . . . . ....

5

Inhaltsverzeichnis

Vorwort. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Über den Autor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Danksagung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Teil I Einführung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

1 Was bedeuten »Design« und »Architektur«? . . . . . . . . . . . . . . . . . . . 291.1 Das Ziel?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301.2 Fallstudie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

1.2.1 Die Signatur des Chaos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321.2.2 Die Perspektive der Unternehmensleitung . . . . . . . . . . . . . . 331.2.3 Was ist schiefgelaufen? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

1.3 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2 Die Geschichte zweier Werte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.1 Verhalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.2 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.3 Der größere Wert. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412.4 Das Eisenhower-Prinzip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422.5 Der Kampf für die Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Teil II Die ersten Bausteine setzen: Programmierparadigmen . . . . . . . . . 45

3 Die Paradigmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.1 Strukturierte Programmierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.2 Objektorientierte Programmierung . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.3 Funktionale Programmierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.4 Denkanstöße . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493.5 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

© des Titels »Clean Architecture« (ISBN 9783958457249) 2018 by mitp Verlags GmbH & Co. KG, Frechen. Nähere Informationen unter: http://www.mitp.de/724

Inhaltsverzeichnis

6

4 Strukturierte Programmierung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.1 Die Beweisführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.2 Eine »schädliche« Proklamation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.3 Funktionale Dekomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.4 Keine formalen Beweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.5 Wissenschaft als Rettung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.6 Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.7 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5 Objektorientierte Programmierung . . . . . . . . . . . . . . . . . . . . . . . . . . . 595.1 Datenkapselung? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605.2 Vererbung? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635.3 Polymorphie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.3.1 Die Macht der Polymorphie . . . . . . . . . . . . . . . . . . . . . . . . . . . 675.3.2 Abhängigkeitsumkehr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.4 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

6 Funktionale Programmierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736.1 Quadrierung von Integern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 746.2 Unveränderbarkeit und Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . 756.3 Unterteilung der Veränderbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766.4 Event Sourcing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776.5 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Teil III Designprinzipien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

7 SRP: Das Single-Responsibility-Prinzip . . . . . . . . . . . . . . . . . . . . . . . . 857.1 Symptom 1: Versehentliche Duplizierung . . . . . . . . . . . . . . . . . . . . . . 867.2 Symptom 2: Merges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 887.3 Lösungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 897.4 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

8 OCP: Das Open-Closed-Prinzip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 918.1 Ein Gedankenexperiment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 928.2 Richtungssteuerung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 958.3 Information Hiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 958.4 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

9 LSP: Das Liskov’sche Substitutionsprinzip . . . . . . . . . . . . . . . . . . . . . 979.1 Gesteuerte Nutzung der Vererbung . . . . . . . . . . . . . . . . . . . . . . . . . . . 98


Inhaltsverzeichnis

7

9.2 Das Quadrat-Rechteck-Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 989.3 Das LSP und die Softwarearchitektur . . . . . . . . . . . . . . . . . . . . . . . . . 999.4 Beispiel für einen Verstoß gegen das LSP . . . . . . . . . . . . . . . . . . . . . . 999.5 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

10 ISP: Das Interface-Segregation-Prinzip . . . . . . . . . . . . . . . . . . . . . . . . 10310.1 Das ISP und die Programmiersprachen . . . . . . . . . . . . . . . . . . . . . . . 10410.2 Das ISP und die Softwarearchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . 10510.3 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

11 DIP: Das Dependency-Inversion-Prinzip. . . . . . . . . . . . . . . . . . . . . . . 10711.1 Stabile Abstraktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10811.2 Factories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10911.3 Konkrete Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11011.4 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Teil IV Komponentenprinzipien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

12 Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11312.1 Eine kurze Historie der Komponenten . . . . . . . . . . . . . . . . . . . . . . . . 11412.2 Relokatierbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11612.3 Linker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11712.4 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

13 Komponentenkohäsion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12113.1 REP: Das Reuse-Release-Equivalence-Prinzip. . . . . . . . . . . . . . . . . . . 12113.2 CCP: Das Common-Closure-Prinzip . . . . . . . . . . . . . . . . . . . . . . . . . . 123

13.2.1 Ähnlichkeiten mit dem SRP . . . . . . . . . . . . . . . . . . . . . . . . . . 12413.3 CRP: Das Common-Reuse-Prinzip . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

13.3.1 Relation zum ISP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12513.4 Das Spannungsdiagramm für die Komponentenkohäsion . . . . . . . . 12513.5 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

14 Komponentenkopplung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12914.1 ADP: Das Acyclic-Dependencies-Prinzip. . . . . . . . . . . . . . . . . . . . . . . 129

14.1.1 Der wöchentliche Build . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13014.1.2 Abhängigkeitszyklen abschaffen . . . . . . . . . . . . . . . . . . . . . . . 13114.1.3 Auswirkung eines Zyklus in einem Komponenten-

abhängigkeitsgraphen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13314.1.4 Den Zyklus durchbrechen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13414.1.5 Jitters (Fluktuationen) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135


Inhaltsverzeichnis

8

14.2 Top-down-Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13614.3 SDP: Das Stable-Dependencies-Prinzip . . . . . . . . . . . . . . . . . . . . . . . . 137

14.3.1 Stabilität. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13714.3.2 Stabilitätsmetriken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13914.3.3 Nicht alle Komponenten sollten stabil sein . . . . . . . . . . . . . . 141

14.3.4 Abstrakte Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14314.4 SAP: Das Stable-Abstractions-Prinzip . . . . . . . . . . . . . . . . . . . . . . . . . 143

14.4.1 Wo werden die übergeordneten Richtlinien hinterlegt? . . . . 14314.4.2 Einführung in das SAP (Stable-Abstractions-Prinzip) . . . . . . 14314.4.3 Bemessung der Abstraktion. . . . . . . . . . . . . . . . . . . . . . . . . . . 14414.4.4 Die Hauptreihe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14414.4.5 Die »Zone of Pain« . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14514.4.6 Die »Zone of Uselessness« . . . . . . . . . . . . . . . . . . . . . . . . . . . 14614.4.7 Die Ausschlusszonen vermeiden . . . . . . . . . . . . . . . . . . . . . . 14714.4.8 Abstand von der Hauptreihe . . . . . . . . . . . . . . . . . . . . . . . . . . 147

14.5 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

Teil V Softwarearchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

15 Was ist Softwarearchitektur?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15315.1 Entwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15515.2 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15515.3 Betrieb. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15615.4 Instandhaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15715.5 Optionen offenhalten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15715.6 Geräteunabhängigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15915.7 Junk Mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16115.8 Physische Adressierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16215.9 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

16 Unabhängigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16516.1 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16516.2 Betrieb. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16616.3 Entwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16716.4 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16716.5 Optionen offenhalten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16816.6 Layer entkoppeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16816.7 Use Cases entkoppeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16916.8 Entkopplungsmodi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170


Inhaltsverzeichnis

9

16.9 Unabhängige Entwickelbarkeit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17116.10 Unabhängige Deploybarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17116.11 Duplizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17116.12 Entkopplungsmodi (zum Zweiten) . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

16.12.1 Welcher Modus ist am besten geeignet? . . . . . . . . . . . . . . . . 17316.13 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

17 Grenzen: Linien ziehen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17517.1 Ein paar traurige Geschichten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17617.2 FitNesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17917.3 Welche Grenzen sollten Sie ziehen – und wann? . . . . . . . . . . . . . . . . 18117.4 Wie verhält es sich mit der Ein- und Ausgabe? . . . . . . . . . . . . . . . . . . 18417.5 Plug-in-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18517.6 Das Plug-in-Argument . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18617.7 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

18 Anatomie der Grenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18918.1 Grenzüberschreitungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18918.2 Der gefürchtete Monolith . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19018.3 Deployment-Komponenten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19218.4 Threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19218.5 Lokale Prozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19318.6 Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19318.7 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

19 Richtlinien und Ebenen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19519.1 Ebene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19619.2 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

20 Geschäftsregeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20120.1 Entitäten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20220.2 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20320.3 Request-and-Response-Modelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20520.4 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

21 Die schreiende Softwarearchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . 20721.1 Das Thema einer Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20821.2 Der Zweck einer Softwarearchitektur . . . . . . . . . . . . . . . . . . . . . . . . . 20821.3 Aber was ist mit dem Web? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20921.4 Frameworks sind Tools, keine Lebenseinstellung . . . . . . . . . . . . . . . 20921.5 Testfähige Architekturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21021.6 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210


Inhaltsverzeichnis

10

22 Die saubere Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21122.1 Die Abhängigkeitsregel (Dependency Rule) . . . . . . . . . . . . . . . . . . . . 213

22.1.1 Entitäten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21322.1.2 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21322.1.3 Schnittstellenadapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21422.1.4 Frameworks und Treiber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21422.1.5 Nur vier Kreise? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21522.1.6 Grenzen überschreiten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21522.1.7 Welche Daten überqueren die Grenzlinien? . . . . . . . . . . . . . 216

22.2 Ein typisches Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21622.3 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

23 Presenters und »Humble Objects«. . . . . . . . . . . . . . . . . . . . . . . . . . . . 21923.1 Das Pattern »Humble Object« . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21923.2 Presenters und Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22023.3 Das Testen und die Softwarearchitektur . . . . . . . . . . . . . . . . . . . . . . . 22123.4 Datenbank-Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22123.5 Data Mappers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22123.6 Service Listeners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22223.7 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222

24 Partielle Grenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22324.1 Den letzten Schritt weglassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22424.2 Eindimensionale Grenzen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22424.3 Fassaden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22524.4 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226

25 Layer und Grenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22725.1 Hunt the Wumpus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22825.2 Saubere Architektur? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22925.3 Datenstromüberschreitungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23125.4 Datenströme teilen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23225.5 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234

26 Die Komponente Main . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23526.1 Das ultimative Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23526.2 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

27 Services – große und kleine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24127.1 Servicearchitektur?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241


Inhaltsverzeichnis

11

27.2 Vorteile der Services? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24227.2.1 Denkfalle: Entkopplung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24227.2.2 Denkfalle: Unabhängige Entwickel- und Deploybarkeit . . . . 243

27.3 Das Kätzchen-Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24327.4 Objekte als Rettung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24527.5 Komponentenbasierte Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24727.6 Cross-Cutting Concerns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24827.7 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248

28 Die Testgrenze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24928.1 Tests als Systemkomponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24928.2 Design für Testfähigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25028.3 Die Test-API. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

28.3.1 Strukturelle Kopplung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25128.3.2 Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

28.4 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

29 Saubere eingebettete Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25329.1 App-Eignungstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25629.2 Der Flaschenhals der Zielhardware . . . . . . . . . . . . . . . . . . . . . . . . . . . 259

29.2.1 Eine saubere eingebettete Architektur ist eine testfähige eingebettete Architektur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260

29.2.2 Offenbaren Sie dem HAL-User keine Hardwaredetails . . . . 26329.3 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

Teil VI Details. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

30 Die Datenbank ist ein Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27330.1 Relationale Datenbanken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27430.2 Warum sind Datenbanksysteme so weit verbreitet? . . . . . . . . . . . . . . 27430.3 Was wäre, wenn es keine Festplatten gäbe? . . . . . . . . . . . . . . . . . . . . 27530.4 Details. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27630.5 Und was ist mit der Performance? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27630.6 Anekdote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27730.7 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278

31 Das Web ist ein Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27931.1 Der immerwährende Pendelausschlag . . . . . . . . . . . . . . . . . . . . . . . . 28031.2 Quintessenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28131.3 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282


Inhaltsverzeichnis

12

32 Ein Framework ist ein Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28332.1 Framework-Autoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28432.2 Asymmetrische Ehe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28432.3 Die Risiken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28532.4 Die Lösung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28532.5 Hiermit erkläre ich euch zu ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28632.6 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286

33 Fallstudie: Software für den Verkauf von Videos . . . . . . . . . . . . . . . . 28733.1 Das Produkt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28733.2 Use-Case-Analyse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28833.3 Komponentenarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28933.4 Abhängigkeitsmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29133.5 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291

34 Das fehlende Kapitel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29334.1 Package by Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29434.2 Package by Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29534.3 Ports and Adapters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29734.4 Package by Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29934.5 Der Teufel steckt in den Implementierungsdetails. . . . . . . . . . . . . . . 30434.6 Organisation vs. Kapselung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30534.7 Andere Entkopplungsmodi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30834.8 Fazit: Der fehlende Ratschlag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309

A Architekturarchäologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311A.1 Das Buchhaltungssystem für die Gewerkschaft . . . . . . . . . . . . . . . . . 312A.2 Zurechtschneiden mit dem Laser. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317A.3 Monitoring von Aluminiumspritzguss . . . . . . . . . . . . . . . . . . . . . . . . 321A.4 4-TEL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322

A.4.1 Service Area Computer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326A.4.2 Ermittlung des Wartungsbedarfs . . . . . . . . . . . . . . . . . . . . . . 327A.4.3 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327A.4.4 Die große Neugestaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329A.4.5 Europa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330A.4.6 SAC: Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330

A.5 Die Programmiersprache C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331A.5.1 C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332

A.6 BOSS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332


Inhaltsverzeichnis

13

A.7 Projekt CCU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333A.7.1 Denkfalle: Die Planung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334

A.8 DLU/DRU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335A.8.1 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336

A.9 VRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337A.9.1 Der Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338A.9.2 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338A.9.3 VRS: Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339

A.10 Der Elektronische Rezeptionist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340A.10.1 Der Untergang des ER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341

A.11 Craft Dispatch System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342A.12 Clear Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344

A.12.1 Die Gegebenheiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345A.12.2 Uncle Bob . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346A.12.3 Das Telefongespräch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346

A.13 ROSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347A.13.1 Fortsetzung der Debatten ... . . . . . . . . . . . . . . . . . . . . . . . . . . 348A.13.2 ... unter anderem Namen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348

A.14 Prüfung zum eingetragenen Architekten . . . . . . . . . . . . . . . . . . . . . . 349A.15 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352

B Nachwort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353

Stichwortverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357


15

Vorwort

Worüber reden wir, wenn wir uns über »Architektur« im Allgemeinen unterhalten?

Wie bei allen metaphorischen Annäherungen kann auch die Betrachtung einerSoftware unter architektonischen Gesichtspunkten gleichermaßen viel verhüllenwie offenbaren. Ebenso kann sie mehr versprechen, als sie zu liefern imstande ist,oder mehr liefern, als sie ursprünglich zu versprechen schien.

Der offenkundige Reiz der Architektur besteht in ihrer Struktur, deshalb stehtLetztere auch im Bereich der Softwareentwicklung im Fokus sämtlicher Paradig-men und Überlegungen – Komponenten, Klassen, Funktionen, Module, Layerund Services, egal, ob Mikro oder Makro. Allerdings erweist sich die Gesamtstruk-tur vieler Softwaresysteme nicht selten als fragwürdig oder widersinnig – etwa wiedie sowjetischen Kollektivbetriebe, die als Vermächtnis für das Volk bestimmtwaren, undenkbare Jenga-Türme, die bis zum Himmel hinaufragen, oder wunder-same, unter riesigen Schlammlawinen begrabene archäologische Fundschichten.Dass Softwarestrukturen in der gleichen Art und Weise unserer Intuition folgen,wie dies auch bei Gebäudestrukturen der Fall ist, lässt sich häufig nur schwererkennen.

Gebäude besitzen dagegen eine unübersehbare physische Struktur – ob in Steinoder Beton verwurzelt, ob hoch nach oben ragend oder weit in die Breite verlau-fend, ob groß oder klein, ob atemberaubend oder schlicht und banal. Bei Bauwer-ken gibt es kaum eine Alternative, als sie nach der Physik der Schwerkraft und denverwendeten Materialien auszurichten. Im Gegensatz dazu hat Software – außerim Sinne der Realitätstreue – wenig für die Schwerkraft übrig. Und worausbesteht Software? Anders als Gebäude, die aus Ziegeln, Beton, Holz, Stahl undGlas gefertigt werden, ist Software eben nur aus Software gemacht. Große Soft-warekonstrukte setzen sich aus kleineren Softwarekomponenten zusammen, diewiederum aus noch kleineren Softwarekomponenten bestehen und so weiter, undso fort. Oder, wie es Stephen W. Hawking in seinem Buch »Eine kurze Geschichteder Zeit« ausdrückt:

Da stehen lauter Schildkröten aufeinander.1

Wenn wir über Softwarearchitektur im Speziellen reden, geht es darum, dass Soft-ware in ihrer Beschaffenheit rekursiv und fraktal, im Code prägnant und richtung-

1 Stephen W. Hawking, Eine kurze Geschichte der Zeit, Rowohlt Verlag, 2004.


Vorwort

16

weisend ist. Einfach alles hat mit Details zu tun. Zwar spielen ineinandergreifendeDetailebenen auch bei der Architektur von Gebäuden eine Rolle, in Bezug aufSoftware ist es allerdings kaum sinnvoll, über physische Maßstäbe nachzudenken.Software besitzt eine Struktur – eigentlich jede Menge und zahlreiche Arten vonStrukturen –, deren Vielfalt das Spektrum der physischen Gebäudestrukturen pro-blemlos in den Schatten stellt. Man kann durchaus behaupten, dass dem Designin der Softwareentwicklung mehr Einsatz und Aufmerksamkeit zuteilwird, alsdies in der Gebäudearchitektur der Fall ist – und insofern ist es auch nicht unbe-dingt abwegig, die Softwarearchitektur als architektonischer zu betrachten als dieGebäudearchitektur!

Aber physische Maßstäbe sind für den menschlichen Verstand besser zu begrei-fen. Sie bieten uns Orientierung in der Welt, deshalb halten wir stets Ausschaudanach. Und sicherlich sind die einzelnen Kästen in schematischen PowerPoint-Darstellungen ansprechend und vermitteln einen klaren visuellen Eindruck, trotz-dem geben sie nicht den vollen und lückenlosen Umfang der Architektur einesSoftwaresystems wider. Zweifellos bieten sie eine bestimmte Sicht auf einen archi-tektonischen Aufbau; die Kästen allerdings fälschlicherweise mit dem großenGanzen – also der Architektur selbst – zu verwechseln, heißt definitiv, das großeGanze – und somit die Architektur als solche – aus den Augen zu verlieren: Soft-warearchitektur sieht nicht irgendwie besonders aus. Eine spezifische Visualisie-rung ist eine Entscheidungsfrage, keine Gegebenheit. Vielmehr handelt es sichum eine Entscheidung, die auf einer weiteren Auswahl von Möglichkeiten basiert,nämlich: was enthalten sein soll, was durch Form oder Farbgebung hervorgeho-ben werden soll, was durch Gleichförmigkeit oder Auslassung heruntergespieltwerden soll. Eine Sichtweise hat gegenüber einer anderen nichts Natürliches oderIntrinsisches an sich.

Nun mag es nicht viel Sinn machen, sich im Kontext der Softwarearchitekturmit physikalischen Gesetzmäßigkeiten und physischen Maßstäben auseinan-derzusetzen, dennoch müssen wir auch in diesem Bereich bestimmte physi-sche Einschränkungen bedenken und entsprechend berücksichtigen. Pro-zessorgeschwindigkeiten und Netzwerkbandbreiten können ein hartes Urteilüber die Performance eines Systems fällen. RAM- und Datenspeicherkapazitä-ten können den Ambitionen jeder Codebasis Grenzen setzen. Software mageiner dieser Stoffe sein, aus denen Träume gemacht sind, sie wird aber trotzallem in einer physischen Welt betrieben.

Das ist das Ungheuerliche in der Liebe, dass der Wille unendlich ist und dieAusführung beschränkt, dass das Verlangen grenzenlos ist und die Tat einSklave der Beschränkung.

– William Shakespeare2

2 Shakespeare, Troilus und Cressida, um 1601, Erstdruck 1610, erste deutsche Übers. von Johann Joachim Eschenburg, 1777. Hier übersetzt von Wolf Graf Baudissin, Georg Andreas Reimer, Berlin, 1832.


Vorwort

17

Es ist die physische Welt, in der wir ebenso wie unsere Unternehmen und unsereVolkswirtschaften existieren. Und diese Tatsache liefert uns einen weiteren Kali-brierungsgesichtspunkt, anhand dessen wir die Softwarearchitektur verstehenkönnen – andere, weniger physische Kräfte und Größen, auf deren Grundlage wiruns verständigen und argumentieren können.

Architektur repräsentiert die signifikanten Designentscheidungen, die ein Sys-tem formen und gestalten, wobei die Signifikanz an den Kosten von Änderun-gen bemessen wird.

– Grady Booch

Zeit, Geld und Aufwand geben uns einen Maßstab vor, um das Große und dasKleine, das Wesentliche und das weniger Wesentliche zu sortieren und die archi-tektonischen Aspekte von dem Rest zu unterscheiden. Dieser Maßstab sagt unsauch, wie wir feststellen können, ob eine Architektur gut ist oder nicht: Eine guteSoftwarearchitektur erfüllt die Bedürfnisse aller User, Entwickler und ProductOwner (Produkteigentümer), und zwar nicht nur zu einem gegebenen Zeitpunkt,sondern langfristig.

Wenn Sie denken, eine gute Architektur sei teuer, dann probieren Sie es malmit einer schlechten.

– Brian Foote und Joseph Yoder

Die Modifikationen und Anpassungen, die im Rahmen einer Systementwicklungtypischerweise vorzunehmen sind, sollten nicht von der Art sein, dass sie kostspie-lig und schwer zu realisieren sind und eine jeweils eigene Projektverwaltungerforderlich machen, sondern in die täglichen und wöchentlichen Arbeitsabläufeeingebunden werden können.

Und das bringt uns zu einem nicht unerheblichen Physik-orientierten Problem:der Zeitreise. Wie wissen wir, welcher Art diese typischen Modifikationen bzw.Anpassungen sein werden, sodass wir die damit einhergehenden signifikantenEntscheidungen darauf ausrichten können? Wie reduzieren wir den zukünftigenEntwicklungsaufwand und die Kosten, ohne Kristallkugeln und Zeitmaschinen zuHilfe zu nehmen?

Architektur ist die Menge der Entscheidungen, von denen Sie wünschten, dassSie sie bereits frühzeitig in einem Projekt richtig treffen, bei denen die Wahr-scheinlichkeit, sie auch tatsächlich richtig zu fällen, aber nicht unbedingthöher ist als bei allen anderen Entscheidungen auch.

– Ralph Johnson

Das Vergangene zu verstehen, ist schon schwierig genug. Unser Verständnis vondem Gegenwärtigen ist bestenfalls vage – und die Vorhersage des Zukünftigen istalles andere als trivial.

An diesem Punkt verzweigt der Weg in viele Richtungen.


Vorwort

18

Auf dem dunkelsten Pfad wartet die Vorstellung, dass starke und stabile Architek-turen direkte Abkömmlinge von Autorität und Starrheit sind. Ist eine Modifikationkostenintensiv, wird sie verworfen, die ursächlichen Beweggründe werden klein-geredet oder vollständig in bürokratischen Abgründen versenkt. Das Mandat desArchitekten ist total und totalitär – und als Folge davon verkümmert die Architek-tur zu einer Dystopie für ihre Entwickler und eine ständige Quelle der Frustrationfür alle anderen.

Entlang eines anderen Abzweigs richtet sich das Interesse hingegen auf die sau-berste Variante. Hier wird der »Weichheit« der Software Rechnung getragen unddarauf hingearbeitet, sie als vorrangigste Eigenschaft des Systems zu bewahren.Ebenso wird nicht nur die Tatsache berücksichtigt, dass wir auf der Grundlageunvollständigen Wissens arbeiten, sondern auch anerkannt, dass dies für unsmenschliche Wesen zudem etwas ist, worin wir gut sind. Diese Vorgehensweisekommt unseren Stärken mehr entgegen als unseren Schwächen. Wir erschaffenDinge und wir entdecken Dinge. Wir stellen Fragen und führen Experimentedurch. Eine gute Architektur kommt genau dann zustande, wenn wir sie als Reiseund nicht als Ziel verstehen, mehr als einen fortlaufenden Prozess des Untersu-chens denn als unumstößliches Artefakt.

Architektur ist eine Hypothese, die durch Implementierung und Bewertungbewiesen werden muss.

– Tom Gilb

Das Beschreiten dieses Pfades erfordert Sorgfalt und Aufmerksamkeit, Überle-gungen und Beobachtung, Praxis und Prinzipien. Auf den ersten Blick mag sichdies nach einem schleppenden Prozess anhören, im Endeffekt hängt jedoch allesdavon ab, wie Sie den Weg beschreiten.

Der einzige Weg, um schnell voranzukommen, ist gut voranzukommen. – Robert C. Martin

Genießen Sie die Reise.

Kevlin Henney, Mai 2017


19

Einleitung

Der Titel dieses Buches lautet Clean Architecture, zu Deutsch also »Saubere Archi-tektur«. Zugegeben, das ist eine recht selbstbewusst erscheinende Überschrift.Warum also habe ich mich für diesen Titel entschieden – und wieso habe ich die-ses Buch überhaupt geschrieben?

Meine erste Programmzeile tippte ich 1964 im Alter von zwölf Jahren. Mit demSchreiben dieses Buches begann ich im Jahr 2016 – ich programmiere inzwischenalso bereits seit mehr als einem halben Jahrhundert. In all diesen Jahren blieb esnatürlich nicht aus, dass ich ein paar Dinge über das Strukturieren von Soft-waresystemen gelernt habe – Dinge, von denen ich glaube, dass sie auch fürandere nützlich und wertvoll sind.

Dass ich mir dieses Wissen aneignen konnte, ist der Tatsache zu verdanken, dassich in der Vergangenheit sehr viele Systeme entwickelt habe, sowohl große alsauch kleine. Ich errichtete kleine eingebettete Systeme (Embedded Systems)ebenso wie große Stapelverarbeitungssysteme. Außerdem Echtzeit- und Websys-teme. Und nicht zu vergessen Konsolen-Apps, GUI-Anwendungen, Prozesssteue-rungsapplikationen, Spiele, Kontierungssysteme, Telekommunikationssysteme,Designtools, Zeichenanwendungen sowie viele, viele andere Systeme.

Dasselbe gilt für Singlethread-Anwendungen, Multithread-Anwendungen, An-wendungen mit wenigen schwergewichtigen Prozessen, Anwendungen mit vielenleichtgewichtigen Prozessen, Multiprozessoranwendungen, Datenbankanwendun-gen, mathematische Anwendungen, algorithmische Geometrieanwendungen sowieviele, viele andere Anwendungen.

Ich habe wirklich jede Menge Systeme entwickelt und Anwendungen program-miert. Und all diese Projekte brachten mich ausnahmslos zu einer erstaunlichenErkenntnis:

Die Regeln der Architektur sind stets dieselben!

Erstaunlich ist dies vor allem insofern, als sich die Systeme, mit denen ich imLaufe der Jahre befasst war, radikal voneinander unterscheiden. Wie also kommtes, dass sie auf ähnlichen Architekturregeln basieren, wenn sie doch so verschie-den sind? Meine Schlussfolgerung bezüglich dieser Frage lautet: Weil die Regelnder Softwarearchitektur von allen anderen Variablen unabhängig sind.


Einleitung

20

Bedenkt man dann noch den Wandel, der sich in den letzten 50 Jahren im Bereichder Hardware vollzogen hat, ist diese Erkenntnis umso bemerkenswerter. Meineersten Programmierversuche machte ich auf Maschinen von der Größe einesHaushaltskühlschranks, mit einer Taktzeit von einem halben Megahertz, 4 KBKernspeicher, 32 KB Festplattenspeicher und einer Teletype-Schnittstelle, die ge-rade mal zehn Zeichen pro Sekunde zuließ. Und nun sitze ich hier im Bus aufeiner Rundreise durch Südafrika und schreibe dieses Geleitwort auf einem Mac-Book mit vier i7-Prozessorkernen, von denen jeder einzelne mit 2,8 Gigahertzläuft. Dieses Gerät verfügt über 16 GB RAM-Speicher, eine SSD-Festplatte miteiner Kapazität von einem Terabyte und ein Retina-Display mit einer Auflösungvon 2.880x1.800, das in der Lage ist, extrem hochauflösende Videos abzuspielen.Die in den letzten Jahrzehnten in puncto Rechenpower erzielten Fortschritte sindgeradezu atemberaubend. Jede halbwegs vernünftige Analyse wird bestätigen,dass mein MacBook mindestens 1022 Mal leistungsfähiger ist als die ersten Com-puter, mit denen ich seinerzeit vor einem halben Jahrhundert angefangen habe.

Eine 22-fache Zehnerpotenz ist schon eine geradezu unfassbare Größenordnung.Das entspricht der Anzahl der Angströms von der Erde bis nach Alpha Centauri.Oder auch der Anzahl der in dem Kleingeld in Ihrer Hosentasche oder Geldbörseenthaltenen Elektronen. Und doch beschreibt diese Zahl – mindestens – den inzwi-schen erzielten Anstieg der Rechenleistung, wie ich ihn in meiner bisherigenLebenszeit erlebt habe.

Legt man nun diese gigantischen Fortschritte in Bezug auf die Rechnerperfor-mance zugrunde, wie hat sich das dann auf die Software ausgewirkt, die ichschreibe? Es steht außer Frage, dass sie umfangreicher geworden ist: Früher hieltich bereits ein aus 2.000 Zeilen bestehendes Programm für gewaltig – immerhinentsprach das einer etwa fünf Kilo schweren Kiste voller Lochkarten. Im Vergleichdazu gelten heutzutage erst Programme ab 100.000 Zeilen als groß.

Abgesehen davon ist die Software aber auch erheblich performanter geworden.Wir können inzwischen Dinge damit bewerkstelligen, die wir uns in den 1960er-Jahren nicht mal im Traum hätten vorstellen können. Die Science-Fiction-Bücherbzw. -Filme Colossus, Revolte auf Luna und 2001: Odyssee im Weltraum waren alle-samt Versuche, Zukunftsszenarien von unserer aktuellen Gegenwart abzubilden,die jedoch reichlich am Ziel vorbeigeschossen sind. In all diesen Fiktionenherrschte die Vorstellung von riesigen Maschinen mit Empfindungsvermögenoder einem Bewusstsein vor – was wir jedoch stattdessen vorweisen können, sindunglaublich winzige Maschinen, die trotzdem immer noch nur Maschinen sind.

Und es gibt noch eine Sache, die auffällt, wenn man die Software, die uns heutezur Verfügung steht, mit der von damals vergleicht: Sie enthält immer noch diesel-ben Bestandteile. Sie besteht wie gehabt aus if-Anweisungen, Zuweisungskom-mandos und while-Schleifen.


Einleitung

21

Nun mögen Sie einwenden, dass wir mittlerweile auf viel bessere Programmier-sprachen und überlegenere Paradigmen zurückgreifen können – immerhin pro-grammieren wir inzwischen in Java oder C# oder Ruby. Und wir verwendenobjektorientiertes Design. Das ist zwar alles richtig, dennoch ist der Code an sichnach wie vor bloß eine Ansammlung von Sequenzen (Abfolgen), Selektionen (Ver-zweigungen) und Iterationen (Schleifen) – ganz genau so, wie es schon in den1950er- und 1960er-Jahren der Fall war.

Wirft man einen genauen Blick auf die Praxis der Computerprogrammierung,stellt man fest, dass sich in den letzten 50 Jahren tatsächlich nur sehr wenig geän-dert hat. Sicher, die Sprachen sind ein bisschen besser geworden. Und die Toolssind sogar in exorbitantem Maße besser geworden. Die grundlegenden Bausteineeines Computerprogramms selbst haben sich allerdings nicht verändert.

Hätte ich 1966 eine Computerprogrammiererin1 per Zeitreise in das Jahr 2016befördert, sie an mein MacBook mit der IntelliJ-IDE (Integrated DevelopmentEnvironment, integrierte Entwicklungsumgebung) gesetzt und ihr Java gezeigt,hätte sie sicherlich 24 Stunden gebraucht, um sich von dem Schock zu erholen.Aber unmittelbar danach wäre sie bereits in der Lage gewesen, Code zu schreiben– bei genauerer Betrachtung unterscheidet sich Java nämlich gar nicht so sehr vonC oder auch von Fortran.

Im umgekehrten Fall, wenn ich Sie in das Jahr 1966 zurückbeamen und Ihnenzeigen würde, wie Sie PDP-8-Code schreiben und bearbeiten können, indem Siemithilfe einer Teletype-Tastatur, die lediglich zehn Zeichen pro Sekunde schafft,einen Lochstreifen erstellen, müssten Sie sich vermutlich erst einmal 24 Stundenvon der Enttäuschung erholen – doch dann wären Sie ebenfalls in der Lage, Codezu schreiben, denn: Der Code als solcher hat sich schlicht und ergreifend nichtallzu sehr verändert.

Und genau das ist das Geheimnis: Diese Unveränderlichkeit des Codes ist derGrund dafür, dass die Regeln der Softwarearchitektur über die verschiedenen Sys-temtypen und -variationen hinweg so konstant sind. Die Regeln, denen die Soft-warearchitektur unterliegt, sind Regeln hinsichtlich der Anordnung und Zusam-mensetzung der einzelnen Bausteine von Programmen. Und da diese Bausteineallgemeingültig sind und sich nicht verändert haben, sind auch die Regeln fürderen Anordnung gleichermaßen allgemeingültig und unveränderlich.

Nun mögen Programmierer der jüngeren Generation diese Aussage schlichtwegfür Unsinn halten. Möglicherweise beharren sie sogar darauf, dass heutzutagealles neu und anders sei und die Regeln der Vergangenheit passé seien. Diejeni-gen, die so denken, täuschen sich jedoch. Die Regeln haben sich nicht geändert.Trotz all der neuen Programmiersprachen, all der neuen Frameworks und all der

1 Mit hoher Wahrscheinlichkeit hätte es sich hierbei um eine Frau gehandelt, denn damals war die Zunft der Programmierer zum überwiegenden Teil weiblich.


Einleitung

22

Paradigmen sind sie auch heute noch genau dieselben wie 1946, als Alan Turingden ersten Maschinencode schrieb.

Eines hat sich jedoch in der Tat geändert: Damals wussten wir noch nicht, wiediese Regeln genau lauteten. Und deshalb haben wir auch wieder und wiederdagegen verstoßen. Jetzt allerdings, nachdem wir ein halbes Jahrhundert langErfahrungen sammeln konnten, verstehen wir diese Regeln.

Und einzig und allein um genau diese Regeln – diese zeitlosen, unveränderlichenRegeln – geht es in diesem Buch.

Hinweis

Sollte es Updates, Korrekturen oder Ergänzungen zum Buch geben, finden Siediese auf der Webseite des mitp-Verlags unter www.mitp.de/724, sobald sie ver-fügbar sind.


23

Über den Autor

Robert C. Martin (auch bekannt als »Uncle Bob«) istseit 1970 als Softwareprogrammierer tätig. Er ist Mitbe-gründer der Organisation cleancoders.com, die Online-Videotrainings für Softwareentwickler bereitstellt. DesWeiteren gründete er das Unternehmen Uncle BobConsulting LLC, das Dienstleistungen in den Bereichen

IT-Beratung, Training und Skill Development für große Firmen weltweit anbietet.Außerdem war er als Master Craftsman in dem in Chicago ansässigen IT-Consul-ting-Unternehmen 8th Light Inc. beschäftigt. Martin veröffentlichte Dutzende vonArtikeln in diversen Handelsmagazinen und tritt regelmäßig als Redner bei inter-nationalen Konferenzen und Kongressen auf. Er war drei Jahre lang Chefredak-teur des Computermagazins C++ Report und ist zudem Erster Vorsitzender derAgile Alliance, einer gemeinnützigen Organisation zur Förderung der im AgileManifesto festgelegten Konzepte der Agilen Softwareentwicklung.

Martin hat zahlreiche Bücher geschrieben sowie redaktionell bearbeitet, darunterTitel wie Clean Coder: Verhaltensregeln für professionelle Programmierer (mitp, 2014),Clean Code – Refactoring, Patterns, Testen und Techniken für sauberen Code (mitp,2009), UML for Java Programmers (Pearson, 2003), Agile Software Development(Prentice Hall International, 2013), Extreme Programming in Practice (Addison-Wesley, 2001), More C++ Gems (Cambridge University Press, 2000), Pattern Lan-guages of Program Design 3 (Addison-Wesley, 1997) sowie Designing Object OrientedC++ Aplications Using the Booch Method (Prentice Hall, 1995).


24

Danksagung

Die folgenden Personen waren maßgeblich an der Entstehung dieses Buches be-teiligt (in keiner bestimmten Reihenfolge):

Chris Guzikowski

Chris Zahn

Matt Heuser

Jeff Overbey

Micah Martin

Justin Martin

Carl Hickman

James Grenning

Simon Brown

Kevlin Henney

Jason Gorman

Doug Bradbury

Colin Jones

Grady Booch

Kent Beck

Martin Fowler

Alistair Cockburn

James O. Coplien

Tim Conrad

Richard Lloyd

Ken Finder

Kris Iyer (CK)

Mike Carew

Jerry Fitzpatrick

Jim Newkirk

Ed Thelen

Joe Mabel

Bill Degnan

Darüber hinaus gab es noch zahlreiche weitere Mitwirkende, deren namentlicheErwähnung den Rahmen dieser kurzen Danksagung jedoch sprengen würde.

Die finale Überarbeitung des Kapitels Schreiende Architektur rief mir Jim Weirichsstrahlendes Lächeln und sein melodisches Lachen in Erinnerung. Mach’s gut, Jim!


29

Kapitel 1

Was bedeuten »Design« und »Architektur«?

Im Laufe der Jahre sorgte die Verwendung der Begriffe »Design« und »Architek-tur« immer wieder für Verwirrung. Was ist Design? Was ist Architektur? Und woliegt der Unterschied?

Eine der Zielsetzungen dieses Buches besteht darin, Ihnen einen Weg durch dasverworrene Dickicht der Begriffsauslegungen aufzuzeigen und ein für alle Mal zudefinieren, was genau unter Design und Architektur zu verstehen ist. Für denAnfang soll an dieser Stelle zunächst einmal festgehalten werden, dass es eigent-lich keinen Unterschied gibt. Überhaupt keinen Unterschied.

Das Wort »Architektur« wird häufig im Zusammenhang mit Dingen auf einerübergeordneten Ebene verwendet, die sich von den Details auf einer untergeord-neten Ebene unterscheiden. Mit »Design« scheinen dagegen oftmals Strukturenund Entscheidungen auf einer untergeordneten Ebene bezeichnet zu werden.Betrachtet man die Arbeit eines echten Architekten, ist diese Begriffsverwendungjedoch geradezu absurd.


Kapitel 1Was bedeuten »Design« und »Architektur«?

30

Versetzen Sie sich doch einmal in den Architekten, der Ihr neues Haus entwirft.Besitzt dieses Gebäude eine Architektur? Natürlich! Und worin besteht dieseArchitektur? Nun, einerseits beschreibt sie die Gestalt des Hauses – sein äußeresErscheinungsbild, den Aufriss und die Anordnung des Wohnraums bzw. derRäume. Wenn Sie sich jedoch die Planungsentwürfe Ihres Architekten anschauen,werden Sie darin zum anderen auch eine Vielzahl von untergeordneten Detailsentdecken. So ist zum Beispiel ausgewiesen, wo jede einzelne Steckdose, jedereinzelne Lichtschalter und jede einzelne Lampe platziert werden wird. Sie könnensehen, welche Schalter welche Lampen steuern. Ebenso lässt sich feststellen, woder Kamin errichtet werden wird und an welchen Standorten und in welcherGröße der Warmwasserboiler und die Schmutzwasserpumpe installiert werden.Und darüber hinaus werden Sie auch detaillierte Darstellungen der Wand-, Dach-und Fundamentkonstruktionen vorfinden.

Kurz: Die Pläne geben Auskunft über alle winzigen Details, die sämtliche auf derübergeordneten Ebene getroffenen Entscheidungen stützen. Und es wird deut-lich, dass diese untergeordneten Details und die übergeordneten EntscheidungenTeil des Gesamtentwurfs des Hauses sind.

Genauso verhält es sich auch mit dem Softwaredesign. Die untergeordneten (low-level) Details und die übergeordnete (high-level) Struktur sind allesamt Teil dessel-ben Ganzen. Zusammen bilden sie ein durchgängiges Konstrukt, das die Gestaltdes Systems definiert. Das eine kann nicht ohne das andere sein. Tatsächlich gibtes keine eindeutige Grenzlinie zwischen diesen beiden Komponenten – es gibteinfach nur ein Kontinuum an Entscheidungen, die sich von der höchsten bis zuden niedrigsten Ebenen erstrecken.

1.1 Das Ziel?

Und die Zielsetzung dieser Entscheidungen? Das Erreichen eines guten Software-designs? Dieses Ziel entspricht nichts Geringerem als meiner »utopischen«Beschreibung:

Das Ziel der Softwarearchitektur besteht in der Minimierung der menschli-chen Ressourcen, die für das Errichten und die Instandhaltung des benötigtenSystems erforderlich sind.

Die Qualität des Designs bemisst sich schlicht und ergreifend an dem Ausmaßdes Aufwands, der erforderlich ist, um den Bedürfnissen der Kunden gerecht zuwerden. Bedarf es hierfür eines geringen Aufwands und bleibt dies auch währendder gesamten Lebenszeit des Systems so, dann handelt es sich um ein gutesDesign – steigt der Aufwand mit jedem neuen Release, taugt das Design nichts. Soeinfach ist das.


1.2Fallstudie

31

1.2 Fallstudie

Die nachstehende Fallstudie soll hier als Beispiel dienen. Sie weist reale Dateneines echten Unternehmens aus, das jedoch anonym bleiben möchte.

Werfen wir zunächst einen Blick auf den Anstieg des technischen Mitarbeiterstabsim Engineering-Bereich. Sicher werden Sie zustimmen, dass dieser Trend äußerstvielversprechend aussieht. Das in Abbildung 1.1 gezeigte Personalwachstum mussdoch ein Indikator für einen bedeutenden Erfolg sein!

Abb. 1.1: Personalwachstum im Engineering-Bereich (Abdruck mit freundlicher Genehmigung von Jason Gorman)

Betrachten wir als Nächstes die Produktivität des Unternehmens in demselbenZeitraum, und zwar gemessen an den Lines of Code, also der Anzahl der Codezei-len (siehe Abbildung 1.2).

Abb. 1.2: Produktivität über denselben Zeitraum hinweg



32

Hier läuft ganz offenkundig irgendetwas nicht richtig: Obwohl jedes Release unterZuhilfenahme einer stetig steigenden Anzahl von Entwicklern bearbeitet wird,scheint der Code lediglich in einem asymptotischen Verhältnis dazu anzuwachsen.

Was nun folgt, ist allerdings eine noch weitaus besorgniserregendere Grafik:Abbildung 1.3 zeigt, wie sich die Kosten pro Codezeile im Zeitverlauf veränderthaben.

Abb. 1.3: Kosten pro Codezeile im Zeitverlauf

Diese Trendentwicklungen sind definitiv nicht tragbar. Egal, wie profitabel dasUnternehmen zum gegenwärtigen Zeitpunkt auch dastehen mag: Verlaufskurvenwie diese werden die Gewinne des Geschäftsmodells in katastrophaler Art undWeise belasten und die Firma in die Verlustzone treiben – wenn nicht sogar direktin die Pleite.

Doch was in aller Welt hat diese bemerkenswerte Veränderung in Bezug auf dieProduktivität verursacht? Warum war die Codeerstellung für Release Nummer 8gleich 40 Mal teurer als für Release Nummer 1?

1.2.1 Die Signatur des Chaos

Was Sie in den vorstehenden Grafiken gesehen haben, könnte man auch als die»Signatur des Chaos« bezeichnen. Wenn Systeme hastig zusammengeschustertwerden, wenn die schiere Anzahl der Programmierer der alleinige Antrieb für denzu erzielenden Output ist und wenn nur wenige bis gar keine Überlegungen hin-sichtlich der Sauberkeit des Codes oder der Struktur des Designs angestellt werden,dann können Sie gewiss sein, dass Sie den hier demonstrierten eingeschlagenenWeg bis zum bitteren Ende gehen werden.


1.2Fallstudie

33

In Abbildung 1.4 ist zu sehen, wie sich dieser Weg für die Entwickler darstellt: Siehaben mit einer Produktivität von nahezu 100 % angefangen, die dann jedoch mitjedem weiteren Release radikal abfiel. Bereits ab Release Nummer 4 wurde deut-lich, dass ihre Produktivität in einer asymptotischen Annäherung gegen null abfla-chen würde.

Abb. 1.4: Produktivität je Release

Aus Sicht der Entwickler ist das enorm frustrierend, weil sie faktisch alle die ganzeZeit über unvermindert hart an dem Programm weitergearbeitet haben – ohnedass auch nur ein einziger von ihnen seine Anstrengungen verringert hätte.

Und doch, trotz all ihres heroischen Einsatzes, der Überstunden und ihrer Hingabe,bringen sie einfach nicht mehr viel zustande. All ihre Bemühungen entfernen sichzusehends von den Features weg und richten sich nun immer mehr darauf, das ent-standene Chaos zu verwalten. Ihre Aufgabe hat sich somit inzwischen dahin gehendverändert, dass sie jetzt das Chaos von einer Stelle zur nächsten verlagern, und wie-der zur nächsten und übernächsten, damit sie überhaupt noch in der Lage sind,auch nur ein einziges weiteres mickriges Feature zu ergänzen.

1.2.2 Die Perspektive der Unternehmensleitung

Wenn Sie nun glauben, das sei schon übel, dann stellen Sie sich nur einmal vor,wie sich die Sachlage der Führungsebene des Unternehmens darstellt! Abbildung1.5 zeigt die Entwicklung der monatlichen Gehaltszahlungen für denselben Zeit-raum.

Release Nummer 1 wurde bei monatlichen Gehaltszahlungen von wenigen Hun-derttausend US-Dollar fertiggestellt. Das zweite Release kostete bereits ein paarHunderttausend Dollar mehr. Und mit Release Nummer 8 hatten die monatlichenZahlungen bereits 20 Millionen US-Dollar erreicht, Tendenz steigend!



34

Abb. 1.5: Entwicklung der monatlichen Gehaltszahlungen je Release

Allein dieses Diagramm ist schon erschreckend. Zweifelsohne ist hier irgendetwasAlarmierendes im Busch. Man kann nur hoffen, dass die Erträge die Kosten amEnde übersteigen werden und somit die Ausgaben rechtfertigen – doch egal, wieman diesen Kurvenverlauf auch betrachtet, er gibt in jedem Fall Anlass zur Sorge.

Vergleichen Sie die Kurve in Abbildung 1.5 nun aber mal mit den pro Releasegeschriebenen Codezeilen in Abbildung 1.2. Mit der Investition von ursprünglichwenigen Hunderttausend Dollar pro Monat wurde eine Menge Funktionalitäterzielt – die letzten 20 Millionen Dollar brachten dagegen nahezu nichts! JederCFO bzw. Finanzdirektor wird mit einem Blick auf diese beiden grafischen Dar-stellungen erkennen, dass sofort etwas unternommen werden muss, um diebevorstehende Katastrophe abzuwenden.

Doch was lässt sich dagegen unternehmen? Was ist hier schiefgelaufen? Wodurchwurde dieser unglaubliche Produktivitätsabfall verursacht? Was kann die Manage-mentebene anderes tun, als mit den Füßen aufzustampfen und den Entwicklernihren Unmut kundzutun?

1.2.3 Was ist schiefgelaufen?

Vor fast 2.600 Jahren erzählte der griechische Dichter Äsop die Fabel von derSchildkröte und dem Hasen. Die Moral dieser Geschichte wurde im Laufe der Zeitauf vielerlei unterschiedliche Weise interpretiert:

� »Eile mit Weile.«

� »Nicht den Schnellen gehört im Wettlauf der Sieg, nicht den Tapferen der Siegim Kampf.«

� »Blinder Eifer schadet nur.«

Im Prinzip illustriert diese Fabel die Unvernunft der Selbstüberschätzung: DerHase vertraut dermaßen auf die ihm eigene Schnelligkeit, dass er das Rennennicht ernst genug nimmt und ein Nickerchen hält, während die Schildkröte unter-dessen die Ziellinie überquert.


1.2Fallstudie

35

Moderne Entwickler finden sich in einer ähnlichen Wettbewerbssituation wieder –und stellen eine ganz ähnliche Selbstüberschätzung zur Schau. Allerdings schla-fen sie nicht, ganz im Gegenteil: Die Programmierer von heute arbeiten buchstäb-lich Tag und Nacht. Dennoch: Ein Teil ihres Verstandes befindet sich oftmalstatsächlich im Dämmerschlaf – und zwar der Teil, der im Grunde genommengenau weiß, dass guter, sauberer und ordentlich designter Code den entscheiden-den Unterschied macht.

Diese Entwickler erliegen einer landläufigen Illusion: »Aufräumen können wirspäter immer noch, jetzt müssen wir das System aber zuerst mal auf den Marktbringen!« Allerdings wird der Code im Nachhinein natürlich nicht mehr aufge-räumt – ganz einfach weil der Marktdruck niemals nachlässt. Ist die Markteinfüh-rung erst einmal vollzogen, hat man sofort eine Horde von Wettbewerbern auf denFersen, denen man um jeden Preis vorausbleiben muss, indem man im übertra-genen Sinne so schnell rennt, wie man nur kann.

Dementsprechend wird den Programmierern zu keinem Zeitpunkt ein Wechselihres Arbeitsmodus gelingen. Sie können nicht zurück und den vorhandenenCode säubern, weil sie schon gleich wieder das nächste Feature fertigstellen müs-sen – und das nächste und das nächste und das nächste. So häuft sich immermehr Unordnung an, und in der Konsequenz nimmt die Produktivität einen ziel-strebigen asymptotischen Verlauf gegen null.

Ebenso wie der Hase der Selbstüberschätzung seiner Schnelligkeit erlag, verfallenauch die Entwickler einer Selbstüberschätzung in Bezug auf ihre Fähigkeit, pro-duktiv zu bleiben. Das Chaos, das sich in den Code einschleicht und ihre Produk-tivität beeinträchtigt, setzt sich somit unerbittlich fort. Und wenn diesem Prozessnicht Einhalt geboten wird, reduziert er ebendiese Produktivität binnen wenigerMonate auf null.

Ein noch gravierenderer Trugschluss, dem die Entwickler erliegen, ist jedoch dieVorstellung, dass ihnen das Schreiben von unordentlichem Code kurzfristig einenGeschwindigkeitsvorteil bringen und alles andere auf lange Sicht nur aufhaltenwürde. Programmierer, die diesem Irrglauben aufsitzen, demonstrieren nicht nurdie Selbstüberschätzung des Hasen in Bezug auf ihre Fähigkeit, den Wechsel vomchaotischen Arbeiten zur zukünftigen Beseitigung der angerichteten Unordnungzu vollziehen, sondern begehen darüber hinaus auch einen simplen faktischenFehler, denn: Tatsache ist, dass Unordnung immer für mehr Verzögerungen sorgt alsdie fortgesetzte Einhaltung sauberer Programmierung, unabhängig davon, welcherZeitrahmen zugrunde gelegt wird.

Betrachten Sie in diesem Zusammenhang einmal die Ergebnisse eines bemer-kenswerten, von Jason Gorman unternommenen Experiments, das in Abbildung1.6 veranschaulicht ist. Jason führte seine Untersuchungsreihe über einen Zeit-raum von sechs Tagen durch. An jedem dieser Tage stellte er ein einfaches Pro-



36

gramm fertig, das Integer in römische Zahlen umwandelte. Anschließend ließ erden Code jeweils einen Satz von Funktionstests durchlaufen. Verliefen sie erfolg-reich, war seine Arbeit erledigt. Dieser Vorgang nahm pro Tag etwas weniger als30 Minuten in Anspruch. Am ersten, dritten und fünften Tag wandte Jason einebekannte Methode für saubere Softwareentwicklung an, die als Test-DrivenDevelopment (TDD, testgetriebene Entwicklung) bezeichnet wird. An den verblei-benden drei Tagen schrieb er den Code hingegen ohne TDD weiter.

Abb. 1.6: Zeit bis zur Fertigstellung nach Iterationen und Anwendung/Nichtanwendung der TDD-Methode

Auffällig ist in Abbildung 1.6 die Lernkurve: An den späteren Tagen war die Arbeitschneller erledigt als an den vorausgehenden. Beachten Sie auch, dass die Pro-grammierung an den TDD-Tagen um etwa 10 % schneller voranging als an denTagen ohne Anwendung des TDD-Verfahrens und dass Jason selbst am langsams-ten TDD-Tag schneller vorwärtskam als am schnellsten Tag ohne TDD.

Nun mag das Ergebnis dieser Untersuchung so manchen Programmierer inErstaunen versetzen. Für all jene, die nicht der Selbstüberschätzung des Hasenunterliegen, war es jedoch durchaus zu erwarten – weil sie sich einer einfachenWahrheit der Softwareentwicklung bewusst sind:

Der einzige Weg, schnell voranzukommen, ist, auf die richtige Art und Weisevorzugehen.

Und das ist auch die Antwort auf das Dilemma der Führungsebene: Der einzigeWeg, dem Produktivitätsabfall und dem Kostenanstieg entgegenzuwirken, bestehtdarin, die Programmierer davon abzubringen, sich die Denkweise des sich selbstüberschätzenden Hasen anzueignen, sondern stattdessen anzufangen, Verantwor-tung für das von ihnen verursachte Chaos zu übernehmen.


1.3Fazit

37

Die Entwickler mögen ihrerseits hingegen die Auffassung vertreten, die Antwortbestünde darin, noch mal ganz von vorn anzufangen und das gesamte System neuzu designen – aber damit hätte der Hase dann doch wieder die Oberhand gewon-nen, denn: Dieselbe Selbstüberschätzung, die überhaupt erst zu dem angerichte-ten Chaos geführt hat, würde ihnen an dieser Stelle wiederum vorgaukeln, siekönnten es besser machen, wenn sie nur einen Neustart des Rennens bewirkenkönnten. Die Realität sieht jedoch weniger rosig aus:

Ihre Selbstüberschätzung wird das Redesign in genau dasselbe Chaos stürzen,wie es schon beim ursprünglichen Projektansatz der Fall war.

1.3 Fazit

Die beste Option für das Entwicklungsteam ist in jedem Fall, seine eigene Selbst-überschätzung zu erkennen, sie abzustellen und stattdessen anzufangen, die Qua-lität seiner Softwarearchitektur ernster zu nehmen.

Dazu muss man sich natürlich darüber im Klaren sein, was eine gute Softwarear-chitektur überhaupt ausmacht. Um ein System zu errichten, dessen Design undArchitektur eine Minimierung des zu betreibenden Aufwands und eine Maximie-rung der Produktivität gewährleisten, müssen Sie wissen, welche Attribute derSystemarchitektur zum Erreichen dieses Ziels führen.

Und genau das ist es, womit sich dieses Buch befasst. Es beschreibt, wie gute, sau-bere Architekturen1 und Designs aussehen, damit Softwareentwickler Systemebauen können, die eine lange und gewinnbringende Lebensdauer erzielen.

1 Um den Lesefluss in deutschen Sätzen zu erleichtern, wird der Begriff »Clean Architecture« in diesem Buch sinngemäß mit »saubere Architektur« übersetzt.


357

Stichwortverzeichnis

3DBB (Three-Dimensional Black Board) 3434-TEL 322, 334, 3378085-Hardware 3318085-Mikroprozessor 3238086-Mikrocomputer 329.jar-Datei

Download-and-Go-Regel 179Entkopplungsmodus auf Quellcode-

Ebene 192Komponenten als .jar-Datei 113Komponentenarchitektur 290komponentenbasierte Services designen

247Komponentendefinition 303partielle Grenze erstellen 224

.NETKomponenten als DLLs 113

AAbhängigkeiten 70

architektonisches Framework für Richt-linien 196

Auswirkungen auf Software 254Beispiel OCP 92Common-Reuse-Prinzip 124Stabilitätsmetriken berechnen 139transitive 95unerwünschte verwalten 109unverwaltete 254von Komponenten verstehen 137

Abhängigkeiten, ADP siehe ADP (Acyclic-Dependencies-Prinzip)

Abhängigkeitsgraph siehe Komponentenab-hängigkeitsgraph

AbhängigkeitsmanagementAbhängigkeitsregel 291für vollwertige architektonische Grenzen

223Vererbungsbeziehungen 291

AbhängigkeitsregelAbhängigkeitsmanagement 291Beispiel saubere Architektur 217Definition 110Entitäten 213

Frameworks 214Framework-Verstöße 285Grenzen überschreiten 215grenzüberschreitende Daten 216im Adventurespiel Hunt the Wumpus

229objektorientierter Ansatz für Cross-Cut-

ting Concerns 248Schnittstellenadapter 214Services 242Services zur Einhaltung der 248Tests gemäß der 250Treiber 214Übersicht 213und saubere Architektur 213Use Cases 213

Abhängigkeitsumkehrobjektorientierte Programmierung 68

Abhängigkeitsumkehrung 317Abhängigkeitsverwaltung

mittels Polymorphie in monolithischen Systemen 190

Abhängigkeitszyklus siehe Komponentenab-hängigkeitsgraph

Abstract Factories 109Abstrakte Klassen

Dependency-Inversion-Prinzip und 107Fazit 149in Zone of Uselessness übrig gebliebene

146Services in Java 247übergeordnete Richtlinien hinterlegen

143Abstrakte Komponenten 143Abstraktionen

stabile 108und Quellcode-Abhängigkeiten 107

ADP (Acyclic-Dependencies-Prinzip)Abhängigkeitszyklen abschaffen 131Auswirkung eines Zyklus im Kompo-

nentenabhängigkeitsgraphen 133Jitters (Fluktuationen) 135Übersicht 129wöchentlicher Build 130Zyklus durchbrechen 134



358

Agile Manifesto 23Akteure 86Aktualisierungen

nebenläufige 75Aluminiumspritzguss 321Anpassung

einfache 40Anwendungsfälle siehe Use CasesAnwendungsspezifische Geschäftsregeln

Use Cases 204, 213APIs

Tests 251App-Eignungstest 256Architektur

als Systemwert 40Eisenhower-Prinzip 42Microservice- 342richtig hinbekommen 27serviceorientierte 341und ISP 105und LSP 99und Unveränderbarkeit 75vor Funktionalität 41vs. Design 29vs. Funktionalität 41

Archiveals Komponentenaggregation 113

ASC Tabulating 312Asymmetrische Ehe

mit Framework-Autoren 284Ausführbare Dateien

Deployment von Monolithen 190Komponenten verknüpfen als ausführ-

bare Dateien 113Ausgehende Abhängigkeiten

Stabilitätsmetriken 139Ausmaß

von Systemänderungen 40Ausschlusszonen

Beziehung zwischen Abstraktion und Stabilität 145

vermeiden 147Automat

endlicher 342Automatisierte Systeme

Geschäftsregeln 203Autoren

Framework 284

BBasisklassen

Frameworks 284

BCE(Boundary Control Entity)-Systemarchi-tektur 211

Beck, Kent 256Beispiel

Kätzchen-Problem 243Betriebssystem (OS)

als Detail 266Beweisführung 52

in der strukturierten Progammierung 55Bibliotheken

Adresse des Quellcodes 115relokatierbare Binärdateien 117

BinärdateienRelokatierbarkeit 116

Böhm, Corrado 53Booch-Diagramm 347BOSS (Basic Operating System and

Scheduler 332Boston Systems Office 332BPEL (Business Process Execution

Language) 343Brooks, Fred 256Buchhaltungssystem 312Build

wöchentlicher 130

CC 331, 332

Datenkapselung 60Polymorphie in 65Vererbung 63

C4 Software Architecture Model 304C#

Abhängigkeitsumkehr 69abstrakte Komponenten 143Anweisungen für Abhängigkeiten ver-

wenden 196geminderte Datenkapselung 62

C++Abhängigkeiten 140Ehe mit STL eingehen 286geminderte Datenkapselung 61Polymorphie in 67Vererbung 64

C-Compiler 332CCP (Common-Closure-Prinzip)

Layer entkoppeln 168Modifikationen lokal halten 136Richtlinien in Komponenten gruppieren

198Spannungsdiagramm 126Übersicht 123



359

und SDP (Stable-Dependency-Prinzip) 136

vs. SRP (Single-Responsibility-Prinzip) 124

CDS (Craft Dispatch System) 342Church, Alonzo 48, 73Clean Code 82cleancoders.com 23, 287Clear Communications 344Clojure 74, 77Cockburn, Alistair 211Codd, Edgar 274Code

Kostenanstieg der Gehälter 33Produktivität vs. Kosten 31Signatur des Chaos 32Unvernunft der Selbstüberschätzung 34

Code, Quellcode-Abhängigkeiten siehe Quell-code-Abhängigkeiten

Codeorganisationandere Entkopplungsmodi 308Implementierungsdetails 304Package by Component 299Package by Feature 295Package by Layer 294Ports and Adapters 297Übersicht 293vs. Kapselung 305

Codezeilen 31, 32Common-Closure-Prinzip siehe CCP (Com-

mon-Closure-Prinzip)Common-Reuse-Prinzips siehe CRP (Com-

mon-Reuse-Prinzip)Compare-and-Swap-Algorithmus 77Compiler

Adresse des Quellcodes 114Architekturprinzipien umsetzen 307relokatierbare Binärdateien 116

Constantine, Larry 55Controller

Beispiel saubere Architektur 216Grenzen überschreiten 215saubere Architektur 214

Conway's Law siehe Gesetz von ConwayCoplien, James 211Cross-Cutting Concerns 248CRP (Common-Reuse-Prinzip)

Einfluss auf die Komponentenzusam-menstellung 137

Spannungsdiagramm 126Übersicht 124

DDAG (Directed Acyclic Graph)

architektonisches Framework für Richt-linien 196

Definition 132Komponentenzyklus durchbrechen 134

Dahl, Ole Johan 48Data Mappers 221Datanet 30 312Dateisysteme

Verzögerungen verringern 275Daten

Abhängigkeitsregel 216Beispiel saubere Architektur 216von Funktionen trennen 89

Daten- und Informationsabfragemodelle siehe Request-and-Response-Modelle

DatenbankAbhängigkeitsregel 214als Option offenhalten 209Beispiel saubere Architektur 216Detail 273Gateways 221gegen Geschäftsregeln abgrenzen 180im Adventurespiel Hunt the Wumpus

228in der Entwicklungsphase als Option

offenhalten 158Komponenten abgrenzen 181Layer entkoppeln 169objektorientierte 348Plug-in-Architektur 185relationale 274Schema in der Zone of Pain 146testfähige Architektur erstellen 210unabhängige Entwickelbarkeit 70unabhängige saubere Architektur 212Use Cases entkoppeln 169

Datenbank als DetailAnekdote 277Bedeutung von Datenbanksystemen 274Details 276Fazit 278ohne Festplatten 275Performance 276relationale Datenbanken 274Übersicht 273

Datenkapselungobjektorientierte Programmierung 60

Datenmanagementals Aspekt der Softwarearchitektur 49

Datenmodellvs Datenbank 273



360

DatenspeicherungBedeutung von Datenbanksystemen

dank Festplatten 274Datenströme

teilen 232überschreiten 231und saubere Architektur 231

DCI(Data Context Interaction)-Systemarchi-tektur 211

Deadlocksdurch veränderbare Variablen 75

Deep Thought 329DeMarco, Tom 55Dependency Rule siehe AbhängigkeitsregelDependency-Injection-Framework

Main-Komponente 236Dependency-Inversion-Prinzip siehe DIP

(Dependency-Inversion-Prinzip)Deployment

architekturgestütztes 167Einfluss der Architektur 155Komponenten 192Komponenten als Einheiten 113

Deployment-EbeneEntkopplungsmodi 173

DesignFlüchtigkeit von Schnittstellen reduzie-

ren 108Produktivität vs. Kosten 30richtig hinbekommen 27Signatur des Chaos 32SOLID-Prinzipien 82vs. Architektur 29Zielsetzung 30

Design für Testfähigkeit 250Design Pattern Humble Object

Data Mappers 221Datenbank-Gateways 221Presenters 219Presenters und Views 220Testen und Softwarearchitektur 221

Design Pattern Strategyobjektorientierter Ansatz für Cross-Cut-

ting Concerns 246partielle Grenzen 225

Design Pattern Template Methodobjektorientierter Ansatz für Cross-Cut-

ting Concerns 246Design vs. Architektur

Fazit 37Übersicht 29

Designprinzipien 81Detail

Betriebssystem 266Datenbank 273Frameworks 283Hardware 261, 263Prozessor 263Web 279

Detailsvon Richtlinien trennen 158

Dijkstra, Edsger Wybe 51Beweisführung in der Softwareprogram-

mierung 52Entdeckung der strukturierten Program-

mierung 47Proklamation zu goto-Anweisungen 54Softwaretests 56

DIP (Dependency-Inversion-Prinzip) 84Entitäten ohne Kenntnis der Use Cases

205Factories 109Fazit 110Grenzen überschreiten 215Grenzlinien ziehen 187in guter Softwarearchitektur 92Komponentenzyklus durchbrechen 134konkrete Komponenten 110nicht alle Komponenten sollten stabil

sein 142stabile Abstraktionen 108Übersicht 107und Stable-Abstractions-Prinzip 144

D-MetrikAbstand von der Hauptreihe 147

do/while/until-Anweisungen 47Don’t Repeat Yourself siehe DRY-Prinzip

(Don’t Repeat Yourself)Dreischichtige »Architektur«

als Topologie 176Dringlichkeit

Eisenhower-Prinzip 42DRY-Prinzip (Don’t Repeat Yourself)

bedingte Kompilierungsrichtlinien 269Duplizierung

echte 171echte vs. versehentliche 171versehentliche 86

Dynamisch typisierte Sprachenund DIP 107und ISP 104

Dynamisch verknüpfte Librariesals architektonische Grenze 192



361

EEbenen

und Richtlinien 195Echte Duplizierungen 171Echtzeitbetriebssystem

als Detail 266Educational Testing Service (ETS) 349Ein-/Ausgabe

Definition der Richtlinienebene als Abstand zwischen Ein-/Ausgabe 196

Geschäftsregeln für Use Cases 205Ein-/Ausgabe (I/O)

Komponenten abgrenzen 184Eindimensionale Grenzen 224Eingehende Abhängigkeiten

Stabilitätsmetriken 139Eisenhower-Prinzip 42

Wichtigkeit vs. Dringlichkeit 42Elektronischer Rezeptionist 340Endlicher Automat 342Entitäten

Abhängigkeitsregel 213Beispiel saubere Architektur 216Risiken durch Frameworks 285testfähige Architektur erstellen 210und Geschäftsregeln 202vs. Use Cases 202

Entkopplungauf Quellcode-Ebene 190Beispiel Kätzchen-Problem 243Denkfalle bei Services 242Layer 168Modi 170, 172objektorientierter Ansatz für Cross-Cut-

ting Concerns 245Quellcode-Abhängigkeiten 308Test-API 251unabhängige Deploybarkeit 171unabhängige Entwickelbarkeit 171, 242unabhängiges Deployment 242Use Cases 169

Entkopplungsmodusauf Deployment-Ebene 192

EntwicklerArchitektur vs. Funktionalität 41Eisenhower-Prinzip 43Signatur des Chaos 32Unvernunft der Selbstüberschätzung 34

Entwicklungarchitekturgestützte 167Einfluss der Architektur 155

EnumerationBeweis für Sequenz und Selektion 53

EPROM-Brenner 324Event Sourcing

Transaktionen speichern 78Externe Definition

Compiler 117Externe Komponenten

unabhängige saubere Architektur 212Externe Referenz

Compiler 117Extreme Programming 353

FFallstudie Videoverkaufssoftware

Abhängigkeitsmanagement 291Abläufe/Entscheidungen eines guten

Softwarearchitekten 287Fazit 291Komponentenarchitektur 289Produkt 287Übersicht 287Use-Case-Analyse 288

Fan-in/Fan-out-MetrikenKomponentenstabilität 139

Feathers, Michael 83Fernschreiber 314Festplatten

Aussterben 275Bedeutung für Datenbanksysteme 274

FirewallsGrenzüberschreitungen mittels

Firewalls 189Systemschutz durch Plug-in-Architektur

187Firmware

Auswirkungen veralteter Hardware auf Firmware 253

Definitionen 254Flaschenhals der Zielhardware 259reduzieren 256verschwommene Grenze zwischen Soft-

ware und Firmware 261FitNesse-Programm

partielle Grenze 224Übersicht 179

FLD (Field Labeled Data) 344Flüchtige Komponenten

Design für Testfähigkeit 251flüchtige Software hinterlegen 143problematisch in der Zone of Pain 146Stable-Dependencies-Prinzip 137und Abhängigkeitsgraph 135, 137

Formvon Systemänderungen 40

Fowler, Martin 294



362

Fragile Tests Problem 251Framework als Detail

Fazit 286Framework-Autoren 284Lösung 285Popularität 283Risiken 285Übersicht 283

FrameworksAbhängigkeitsregel 214als Option offenhalten 209als Tools 209Detail 283feste Bindung 286in Softwarearchitekturen vermeiden 208testfähige Architektur erstellen 210unabhängige saubere Architektur 212

Freeman, Steve 211Funktion

Prinzip einer einzigen Aufgabe 85Funktionale Dekomposition

als Best Practice in der Programmierung 57

in der strukturierten Programmierung 55

Funktionale ProgrammierungBeispiel Quadrierung von Integern 74Entstehungsgeschichte 48Event Sourcing 77Fazit 79Übersicht 73Unterteilung der Veränderbarkeit 76Unveränderbarkeit 75

Funktionalitätals Aspekt der Softwarearchitektur 49vs. Architektur 41

FunktionenBeispiele SRP 89gliedern 55konkrete 109nicht überschreiben 109von Daten trennen 89

FunktionsaufrufeServices als Funktionsaufrufe 241

FunktionszeigerEntstehungsgeschichte 48in der objektorientierten Programmie-

rung 48

GGateways

Datenbank 221GE Datanet 30 312

Geheimnisprinzip siehe Information HidingGeräteunabhängigkeit 68

Beispiel 159Beispiel physische Adressierung 162Definition 159I/O-Gerät des UI 282

Gerichteter azyklischer Graph siehe DAG (Directed Acyclic Graph)

Geschäftsdatenkritische 202

Geschäftsregelnandocken 185Design für Testfähigkeit 250Entitäten erstellen 202Fazit 206im Adventurespiel Hunt the Wumpus

228Komponenten abgrenzen 181kritische 202Layer entkoppeln 168mit Richtlinien-Anweisungen berech-

nen 195nah bei den Daten halten 90Request-and-Response-Modelle 205saubere Architektur 212Übersicht 201unabhängige Entwickelbarkeit 70und GUI abgrenzen 184Use Cases 203, 213Use Cases entkoppeln 169von UI entkoppeln 281

Gesetz von Conway 167goto-Anweisungen

Dijkstras Proklamation 54durch iterative Kontrollstrukturen erset-

zen 53Entfernung aus der strukturierten Pro-

grammierung 47Grenzanatomie

Deployment-Komponenten 192Fazit 194gefürchteter Monolith 190lokale Prozesse 193Services 193Threads 192Überschreitungen 189Übersicht 189

Grenze 316Grenzen

Abhängigkeitsregel 215Abhängigkeitsregel für Daten 216Beispiele für architektonische Misser-

folge 176



363

Ein- und Ausgabe (I/O) 184Fazit 187lokale Prozesse 193partiell und eindimensional 224partielle 223Plug-in-Architektur 185Plug-in-Argument 186Services als grenzüberschreitende Funk-

tionsaufrufe 242Services in Komponenten unterteilen

248Tests 249Übersicht 175wo und wann ziehen 181

GrenzüberschreitungBeispiel saubere Architektur 217saubere Architektur 215

Growing Object-Oriented Software with Tests (Freeman & Pryce) 211

GUI (Graphical User Interface)Design für Testfähigkeit 251Ein-/Ausgabe und Grenzlinien 184Plug-in-Architektur 185Plug-in-Argument 187Unit-Test 220von Geschäftsregeln abgrenzen 181von Geschäftsregeln entkoppeln 281Web als Detail 281

GUI (Graphical User Interface) siehe auch UI (User Interface)

HHAL (Hardware Abstraction Layer)

Betriebssystem als Detail 266DRY-bedingte Kompilierungsrichtli-

nien 269Flaschenhals der Zielhardware mit Lay-

ern vermeiden 262Grenze zwischen Software und Firm-

ware 262Hardwaredetails verbergen 263veraltete Firmware 262

Hardware Abstraction Layer siehe HAL (Hardware Abstraction Layer)

Hardware-Abstraktionsschicht siehe HAL (Hardware Abstraction Layer)

HauptreiheAbstand messen 147Ausschlusszonen vermeiden 147Beziehung zwischen Abstraktion und

Stabilität 144Zone of Pain 144Zone of Uselessness 146

Hawking, Stephen W. 15Header-Dateien

Schnittstellen programmieren mit Hea-der-Dateien 263

Hexagonale Architektur (Ports and Adapters) 211

Höhlenerkundung siehe SpelunkingHunt the Wumpus

Main-Komponente 236Hunt, Andrew 269

II/O-Gerät

UNIX-Funktionen 66Web 282

IBM 2314 316IBM System/7 321IBM-3270-Display 321IBM-370-System 321if/then/else-Anweisungen 47Induktionsverfahren

Beweis für Iteration 53Information Hiding

Open-Closed-Prinzip 95Instandhaltung

Einfluss der Architektur 157Integer

Beispiel funktionale Programmierung 74

IntegrationProblemstellung beim wöchentlichen

Build 130Interfaces siehe SchnittstellenInterface-Segregation-Prinzip siehe ISP

(Interface-Segregation-Prinzip)Isolation

Tests 250ISP (Interface-Segregation-Prinzip) 84

Fazit 105Übersicht 103und Architektur 105und Sprachtypen 104vs. CRP (Common-Reuse-Prinzip) 125

Issue-Tracking-System 26Iteration 53

als Programmkontrollstruktur 53

JJacobson, Ivar 208, 211Jacopini, Giuseppe 53Java

abstrakte Komponenten 143Beispiel ISP 104



364

Beispiel Quadrierung von Integern 74Bindung an Standard-Library-Frame-

work 286geminderte Datenkapselung 62import-Anweisungen für Abhängigkei-

ten 196Komponenten als .jar-Dateien in 113Modul-Frameworks 308Package by Layer 294und DIP 107

Jitters (Fluktuationen)Komponentenzyklus durchbrechen 135

JSON 344Junk Mail

Beispiel 161

KKabeldefekt 337Kapselung siehe auch Datenkapselung

übermäßige Verwendung von public und Kapselung 305

vs. Codeorganisation 305Kerncode

Frameworks vermeiden 286Klasse

Definition 82Klassen

Beispiele SRP 89Common-Reuse-Prinzip 124Gliederung von Prozessen in 93LSP für gesteuerte Nutzung der Verer-

bung 98Reuse-Release-Equivalence-Prinzip 122und DIP 107

Klassen, abstrakte siehe Abstrakte KlassenKohäsion

Single-Responsibility-Prinzip 86Kommunikation

als Funktionsaufrufe zwischen Kompo-nenten in Monolithen 194

Gesetz von Conway 167grenzüberschreitend, Deployment-Kom-

ponenten 193grenzüberschreitend, lokale Prozesse

193grenzüberschreitend, Services 194in verschiedenen Entkopplungsmodi 173über entkoppelte Grenzen auf Quell-

code-Ebene 192Kompilierte Programmiersprachen 113Komponenten

abstrakte 109Deployment 192

Entstehungsgeschichte 114Fazit 119konkrete 109, 110Linker 117Prinzipien 111Prozesse in Klassen gliedern 93Relokatierbarkeit 116Tests 249Übersicht 113

KomponentenabhängigkeitsgraphAuswirkung eines Zyklus 133wieder als DAG einsetzen 134

KomponentenarchitekturFallstudie Videoverkaufssoftware 289

Komponentenbasierte SystemeFunktionsaufrufe 242objektorientierter Ansatz für Cross-Cut-

ting Concerns 246Services mit SOLID-Prinzipien designen

247skalierbar errichten 245

KomponentenkohäsionCommon-Closure-Prinzip 123Common-Reuse-Prinzip 124Fazit 127Reuse-Release-Equivalence-Prinzip 121Spannungsdiagramm 125Übersicht 121

KomponentenkopplungFazit 149Fragile Tests Problem 251Stable-Dependencies-Prinzip 137Top-down-Design 136Übersicht 129

Komponentenkopplung, ADP siehe auch ADP (Acyclic-Dependencies-Prinzip)

Komponentenstabilitätbemessen 139und Abstraktion 144verstehen 137

Komponententeilungals Aspekt der Softwarearchitektur 49

Konkrete KomponentenDependency-Inversion-Prinzip 110

Kontrollfluss 68Abhängigkeitsmanagement 291dynamische Polymorphie 190Grenzen überschreiten 215

Kontrollstrukturenin Programmen 53

Kontrollübertragungdirekte 47indirekte 48



365

Kopplungdurch Framework vermeiden 284verfrühte Entscheidungen 175

Kopplung siehe KomponentenkopplungKritische Geschäftsdaten 202Kritische Geschäftsregeln 202Kupferleitungen 334

Lλ-Kalkül siehe Lambda-KalkülLambda-Kalkül 48, 73Laser 318Layer

Ansatz für die Codeorganisation 294Duplizierung 171entkoppeln 168Flaschenhals der Zielhardware vermei-

den 262saubere Architektur 211unabhängige Entwickelbarkeit 171

Layer und GrenzenDatenströme teilen 232Datenstromüberschreitungen 231Fazit 234saubere Architektur 229Übersicht 227

Lebenszyklusarchitekturgestützter 154

Leiningen-ToolModulmanagement 121

Lines of Code siehe CodezeilenLinker

von Loader separieren 118Liskov, Barbara 97Liskov’sches Substitutionsprinzip siehe LSP

(Liskov’sches Substitutionsprinzip)LISP

Beispiel Quadrierung von Integern 74funktionale Programmierung 48

Loaderrelokatierbare Binärdateien 117verknüpfen 117

Locks 75LSP (Liskov’sches Substitutionsprinzip) 84

Fazit 101gesteuerte Nutzung der Vererbung 98Quadrat-Rechteck-Problem 98Übersicht 97und Architektur 99Verstoß 99

MM365 318Mailboxes

Kommunikation zwischen lokalen Pro-zessen 193

Main-Komponenteals ultimatives Detail 235Fazit 239geringfügige Releasefolgen 132Übersicht 235

main-Komponenteals konkrete Komponente 110objektorientierte Programmierung 64Polymorphie 68

ManagementArchitektur vs. Funktionalität 41Eisenhower-Prinzip 43

MarketingkampagnenDatenbankanbieter 278

MathematikBeweisführung 52vs. Wissenschaft 55

Maven-ToolModulmanagement 121

McCarthy, John 48Merges

Beispiele SRP 88Metriken

Abstand von der Hauptreihe 147Abstraktion 144

Metriken für das Abhängigkeitsmanagement siehe ADP (Acyclic-Dependencies-Prinzip)

Meyer, Bertrand 84, 91Microservice-Architektur 342

Beliebtheit 241Deployment-Strategie 156Entkopplungsmodi 170

Minecraft 119Modem 328Modul

Definition 85Module

Common-Reuse-Prinzip 124public vs. published 308Reuse-Release-Equivalence-Prinzip 122

MonolithenDeployment 190Funktionsaufrufe 242lokale Prozesse als statisch verknüpfte

193skalierbare Systeme errichten 243Threads 192vs. Deployment-Ebene 193



366

Moore’sches Gesetz 118Morning-After-Syndrom

durch die Abschaffung von Abhängig-keitszyklen vermeiden 131

Problemstellung beim wöchentlichen Build 130

Übersicht 129zu vermeidende Abhängigkeiten verwal-

ten 131MP/M-86 341

NNational Council of Architects Registry Board

(NCARB) 349Nebenläufige Aktualisierungen 75Netnews 345Nygaard, Kristen 48

OObject-Oriented Software Engineering

(Jacobson) 208, 211Object-Relational Mapping siehe ORMObjektorientierte Datenbank 348Objektorientierte Programmierung

Abhängigkeitsumkehr 68Datenkapselung 60Deployment von Monolithen 190Entstehungsgeschichte 48Fazit 71für Cross-Cutting Concerns 245Hauptkomponenten 60Macht der Polymorphie 67Polymorphie 65Übersicht 59Vererbung 63Vererbungsbeziehungen 70

Objektrelationale Abbildung siehe ORMOCP (Open-Closed-Prinzip) 84, 343

Abhängigkeitsmanagement 291Entstehungsgeschichte 160Fazit 96Gedankenexperiment 92Information Hiding 95komponentenbasierte Services designen

247Richtungssteuerung 95Übersicht 91vs. CCP (Common-Closure-Prinzip) 123

Open-Closed-Prinzip siehe OCR (Open-Clo-sed-Prinzip)

Operating System Abstraction Layer (OSAL)saubere eingebettete Architektur 267

Optionen

durch Entkopplungsmodi 170operationsfördernde Architektur 166,

168zur Erleichterung von Systemänderun-

gen offenhalten 168Zweck einer Softwarearchitektur 154,

208ORM (Object-Relational Mapping) 221OS (Betriebssystem)

als Detail 266OSAL (Operating System Abstraction Layer)

saubere eingebettete Architektur 267Outboard Marine Corporation 321Overlay-System 316

PPackage by Feature 295Package by Layer

horizontale Schichtenarchitektur 294Zugriffsmodifikatoren 304

PackagesOrganisation vs. Kapselung 305

Page-Jones, Meilir 55Partielle Grenzen

eindimensional 224Fassaden 225Fazit 226implementieren 223letzten Schritt weglassen 224Übersicht 223

PDP-11/60 331PDP-8 318Pendelstationen

Web als eine von vielen Pendelstationen 279

Performancetiefschichtiger Mechanismus 276

Périphérique-Ports-and-Adapters-Anti-Pat-tern 309

Personelle RessourcenMinimierung durch Softwarearchitektur

175Physische Adressierung

Beispiel 162Plug-in-Architektur

Annahme einer Plug-in-Architektur 185für Geräteunabhängigkeit 68Grenzen entlang der Modifikationsachse

ziehen 187Main-Komponente 239von untergeordneten Komponenten in

übergeordneten Komponenten 198Policy siehe Richtlinien



367

Policy siehe Übergeordnete RichtlinienPolymorphie

Abhängigkeitsumkehr 68dynamische 190Grenzen überschreiten 215in der objektorientierten Programmie-

rung 48Kontrollfluss in dynamischer Polymor-

phie 190Macht der Polymorphie 67objektorientierte Programmierung 65statische vs. dynamische 190

Ports and AdaptersAbhängigkeiten mit Quellcode-Bäumen

entkoppeln 308Périphérique-Ports-and-Adapters-Anti-

Pattern 309Zugriffsmodifikatoren 306

Positionale StabilitätKomponente 139

Presentation Domain Data Layering (Fowler) 294

PresentersBeispiel saubere Architektur 216Grenzen überschreiten 215Komponentenarchitektur 290saubere Architektur 214

Presenters und Humble ObjectsData Mappers 221Datenbank-Gateways 221Design Pattern Humble Object 219Fazit 222Presenters und Views 220Service Listeners 222Testen und Softwarearchitektur 221Übersicht 219

Problematik fragiler Tests siehe Fragile Tests Problem

ProduktFallstudie Videoverkaufssoftware 287

ProduktivitätSignatur des Chaos 32vs. Kosten 31

ProgrammierparadigmenEntstehungsgeschichte 45Fazit 49Übersicht 47

Programmierparadigmen siehe auch Funktio-nale Programmierung

Programmierparadigmen, funktionale Pro-grammierung siehe Funktionale Program-mierung

Programmierparadigmen, objektorientierte Programmierung siehe Objektorientierte Programmierung

Programmierparadigmen, strukturierte Pro-grammierung siehe Strukturierte Program-mierung

Programmiersprachendynamisch typisierte 107Komponenten 113statisch typisierte 107und abstrakte Komponenten 143und ISP 104Variablen in funktionalen Sprachen 75

Proxiesmit Frameworks nutzen 286

ProzesseGliederung in Klassen 93

Prozessorals Detail 263und Unveränderbarkeit 75

Prüfung zum eingetragenen Architekten 350Pryce, Nat 211public

übermäßige Verwendung 304vs. published 308

publishedvs. public 308

Pythonund DIP 107und ISP 104

QQuadrat-Rechteck-Problem

LSP 98Quellcode

Kompilierung 115Quellcode-Abhängigkeiten

Abhängigkeitsumkehr 68Beispiel OCP 93entkoppeln 197Entkopplung 308Grenzen überschreiten 215Grenzüberschreitungen mittels 189lokale Prozesse als 193nur auf Abstraktionen beziehen 107Wiederverwendung von Spielregeln

durch UI-Komponenten 228Quellcode-Bäume

Abhängigkeiten entkoppeln 308Quellcode-Ebene

Entkopplungsmodi 172



368

RRace Conditions

durch veränderbare Variablen 75Schutz gegen nebenläufige Aktualisie-

rungen 76RAM

als Festplattenersatz 275RAM-Speicher 77RDBMS (Relational Database Management

Systems) 275Real-Time Operating System (RTOS) siehe

EchtzeitbetriebssystemReenskaug, Trygve 211Relational Database Management Systems

siehe RDBMSRelationale Datenbankverwaltungssysteme

siehe RDBMSRelaxed Layered Architecture 300Releases

Abhängigkeitszyklen abschaffen 131Auswirkung eines Zyklus im Kompo-

nentenabhängigkeitsgraphen 133neue Komponenten nummerieren 131Reuse-Release-Equivalence-Prinzip für

neue Releases 122REP (Reuse-Release-Equivalence-Prinzip)

Übersicht 121Request-and-Response-Modelle

Geschäftsregeln 205ReSharper

Plug-in-Argument 186REST-Schnittstelle

Entwicklungsoptionen offenhalten 158Rezeptionist

Elektronischer 340Richtlinien

Datenströme teilen 232Fazit 199in sauberer Architektur 213in Softwaresystemen abbilden 195Übersicht 195

Richtlinien siehe auch Übergeordnete Richtli-nien

RichtungssteuerungOpen-Closed-Prinzip 95

RisikenKosten minimieren 157von Frameworks 285

ROSE 347RTOS (Real-Time Operating System) siehe

Echtzeitbetriebssystem

RubyKomponenten als .gem-Dateien 113und DIP 107und ISP 104

RVM-ToolModulmanagement 121

SSAP (Stable-Abstractions-Prinzip) 143

Abstand von der Hauptreihe 147Abstraktionsmetriken 144Ausschlusszonen vermeiden 147Einführung 143Grenzlinien ziehen 187Hauptreihe 144übergeordnete Richtlinien hinterlegen

143Saubere Architektur

Layer und Grenzen 229Saubere eingebettete Architektur

App-Eignungstest 256Betriebssystem als Detail 266DRY-bedingte Kompilierungsrichtli-

nien 269Fazit 269Flaschenhals der Zielhardware 259Hardware als Detail 261keine Hardwaredetails für HAL-User

263Layer 260Programmierung für Schnittstellen und

Substituierbarkeit 268testfähige eingebettete Architektur 260Übersicht 253

Sauberer Code siehe Clean CodeSchichtenarchitektur

Gründe gegen 299Package by Layer-Codeorganisation 294

Schichtenarchitektur, lässige siehe Relaxed Layered Architecture

Schmidt, Doug 253Schnittstellen

Anwendung des LSPs 99Interface-Segregation-Prinzip 104

SchnittstellenadapterAbhängigkeitsregel 214

Schutzhierarchieauf Ebenengrundlage 95

SDP (Stable-Abstractions-Prinzip)und Stable-Abstractions-Prinzip 144

SDP (Stable-Dependencies-Prinzip)Acyclic-Dependencies-Prinzip 137



369

nicht alle Komponenten sollten stabil sein 141

Stabilität 137Stabilitätsmetriken 139und abstrakte Komponenten 143

SDP (Stable-Dependency-Prinzipund CCP (Common-Closure-Prinzip)

136Selbstüberschätzung

Unvernunft der Selbstüberschätzung 34Selektion

als Programmkontrollstruktur 53Sequenz

als Programmkontrollstruktur 53Service-Ebene

Entkopplungsmodi 173Serviceorientierte Architektur siehe SOA (Ser-

vice-Oriented Architecture)Services

als Funktionsaufrufe vs. Architektur 241als strikteste Grenze 193Cross-Cutting Concerns 248Denkfalle Entkopplung 242Denkfalle unabhängige Entwickel-/

Deploybarkeit 243Fazit 248Humble-Object-Grenzen 222Kätzchen-Problem 243komponentenbasierte 247Objekte als Rettung 245Übersicht 241Vorteile 242

SicherheitTest-API 251

Single-Responsibility-Prinzip siehe SRP (Single-Responsibility-Prinzip)

SkalierbarkeitKätzchen-Problem und Services 243Services nicht die einzige Option 243

SOA (Service-Oriented Architecture)Beliebtheit 241Entkopplungsmodi 170

SocketsKommunikation zwischen lokalen Pro-

zessen 193Software

Flaschenhals der Zielhardware vermei-den 261

Isolierung vom OS durch saubere einge-bettete Architektur 267

richtig hinbekommen 26SOLID-Prinzipien 83

verschwommene Grenze zwischen Firmware und Software 261

SoftwarearchitektenZielsetzung der personellen Ressourcen-

minimierung 175Softwarearchitektur

Beispiel Junk Mail 161Beispiel physische Adressierung 162Definition 153Deployment 155Details von Richtlinien trennen 158drei Hauptaspekte 49Entwicklung 155Fazit 163Geräteunabhängigkeit 159hexagonale 211Optionen offenhalten 157Plug-in- 185Stabilität 143Systembetrieb 156Testen 221Unabhängigkeit 165zur Unterstützung des Systems 154

Softwarearchitektur, saubereAbhängigkeitsregel 213Fazit 217Framework-Verstöße 285typisches Beispiel 216Übersicht 211

Softwarearchitektur, schreiendeFazit 210Frameworks als Tools 209testfähige Architekturen 210übergeordnetes Thema 208Übersicht 207Web 209Zweck 208

SoftwareentitätOCP 91

Softwareentwicklerals Stakeholder 43

SoftwareentwicklungArchitektur vor Funktionalität 43Ausmaß vs. Form von Systemänderun-

gen 40Tests 250wissenschaftliche Beweisführung 56

SoftwarewiederverwendungCommon-Reuse-Prinzip 123Reuse-Release-Equivalence-Prinzip 122und wiederverwendbare Komponenten

122



370

SOLID-PrinzipienEntstehungsgeschichte 82komponentenbasierte Services designen

247objektorientierter Ansatz für Cross-Cut-

ting Concerns 245SOLID-Prinzipien, Dependency-Inversion-

Prinzip siehe DIP (Dependency-Inversion-Prinzip)

SOLID-Prinzipien, Interface-Segregation-Prinzip siehe ISP (Interface-Segregation-Prinzip)

SOLID-Prinzipien, Liskov’sches Substituti-onsprinzip siehe LSP (Liskov’sches Substi-tutionsprinzip)

SOLID-Prinzipien, Open-Closed-Prinzip siehe OCP (Open-Closed-Prinzip)

SOLID-Prinzipien, Single-Responsibility-Prinzip siehe SRP (Single-Responsibility-Prinzip)

Sparcstation 344Speicher

und lokale Prozesse 193Speicher siehe RAM-SpeicherSpeicherreferenzadressen

relokatierbare Binärdateien 116Speicherzuordnung

frühes Layout 115Spelunking

Kosten minimieren 157Sperren siehe LocksSprachausgabe 337Sprachen

im Adventurespiel Hunt the Wumpus 228

und saubere Architektur 229Sprachverarbeitungskarte 340SQL (Structured Query Lanuage 339SRP (Single Responsibility-Prinzip)

Modifikationen lokal halten 136SRP (Single-Responsibility-Prinzip) 83, 86

Abhängigkeitsmanagement 288, 291Fazit 90Grenzen ziehen 187in guter Softwarearchitektur 92Layer entkoppeln 168Lösungen 89Merges 88Richtlinien in Komponenten gruppieren

198Übersicht 85Use-Case-Analyse 288

Stabile Komponentenabstrakte Komponenten als 143harmlos in der Zone of Pain 146nicht alle Komponenten sollten stabil

sein 141Stable-Abstractions-Prinzip 143übergeordnete Richtlinien hinterlegen

143Stakeholder

Architektur vor Funktionalität 43Ausmaß vs. Form von Systemänderun-

gen 40Systemwerte für Stakeholder 39

Statische AnalysetoolsArchitekturverstöße 302

Störfallmeldung 342Struktur

als Systemwert 39Struktur siehe ArchitekturStrukturelle Kopplung

Test-API 251Strukturierte Programmierung 47

Beweisführung 55Dijkstras Proklamation zu goto-Anwei-

sungen 54Entstehungsgeschichte 47Fazit 57funktionale Dekomposition 55Rolle der Wissenschaft 55Softwaretests 56Übersicht 51Wert 57

SubstitutionProgrammierung für Schnittstellen und

268Substitution siehe LSP (Liskov’sches Substitu-

tionsprinzip)Subtypen

Definition 97Sun Microsystems 344Systembetrieb

architekturgestützter Systembetrieb 156, 166

Auswirkungen von Modifikationen auf Use Cases 214

Use Cases entkoppeln 170Systemverhalten 154Systemwerte

Architektur 40Architektur vor Funktionalität 43Eisenhower-Prinzip 42Übersicht 39Verhalten 39



371

TT1-Leitung 344TDD siehe Testgetriebende EntwicklungTelefonsysteme

Europa und USA 330Teradyne Applied Systems 317Teradyne M365 318Terminal mit Kathodenstrahlröhre 314Test-Driven Development siehe Testgetrie-

bene EntwicklungTesten

mit dem Design Pattern Humble Object 219

Presenters und Views 220und Softwarearchitektur 221

Testfähige Architektursaubere eingebettete Architektur als 260Übersicht 210

Testfähige Softwarearchitektursaubere Architektur erstellen 212

Testgetriebene Entwicklung 36Testgrenze

als Systemkomponente 249Design für Testfähigkeit 250Fazit 252Fragile Tests Problem 251Test-API 251Übersicht 249

Testsin der strukturierten Programmierung

56Thomas, David 269Threads

Ausführungszeitplan/-reihenfolge 192und Unveränderbarkeit 75

Ticket 342Ticketsystem 342Top-down-Design

Komponentenstruktur 136Tramp-Daten 205Transaktionaler Speicher 76Transaktionen

speichern 78Transitive Abhängigkeiten

Verstoß gegen Softwareprinzipien 96Treiber

Abhängigkeitsregel 214Turing, Alan 46, 48

UÜbergeordnete Richtlinien

Datenströme teilen 232hinterlegen 143

von Details trennen 157von untergeordneten Ein-/Ausgabe-

Richtlinien entkoppeln 198UI (User Interface)

Flüchtigkeit reduzieren 108im Adventurespiel Hunt the Wumpus

228Programmierung für UI 268unabhängige Entwickelbarkeit 70unabhängige saubere Architektur 212Use Cases entkoppeln 168von Geschäftsregeln entkoppeln 281

UI (User Interface) siehe auch GUI (Graphical User Interface)

UML (Unified Modeling Language) 347UML-Klassendiagramm

Ports and Adapters 299Relaxed Layered Architecture 300

Unabhängige DeploybarkeitBeispiel Kätzchen-Problem 243Denkfalle bei Services 243objektorientierter Ansatz für Cross-Cut-

ting Concerns 245Übersicht 171

Unabhängige EntwickelbarkeitBeispiel Kätzchen-Problem 243Denkfalle bei Services 243objektorientierter Ansatz für Cross-Cut-

ting Concerns 245Übersicht 171UI und Datenbank 70

Unabhängige KomponentenStabilitätsmetriken berechnen 139verstehen 137

Unabhängiges DeploymentTests 250

UnabhängigkeitDeployment 167Duplizierung 171Entkopplungsmodi 170, 172Entwickelbarkeit 171Entwicklung 167Fazit 174Layer entkoppeln 168Optionen offenhalten 168Systembetrieb 166Übersicht 165unabhängige Deploybarkeit 171Use Cases 165Use Cases entkoppeln 169

Uncle Bob 346Unerwünschte Werbung siehe Junk Mail



372

Unit-TestAuswirkung von Zyklen im Komponen-

tenabhängigkeitsgraphen 134mit dem Design Pattern Humble Object

219testfähige Architektur erstellen 210

UNIXI/O-Gerätetreiberfunktionen 66

Unveränderbarkeit 75Upgrades

Risiken durch Frameworks 285Use Cases 203

Abhängigkeitsregel 213als Grundlage für gute Softwarearchitek-

tur 208architekturgestützte 165Duplizierung 171Entkopplungsmodi 169, 170Fallstudie Videoverkaufssoftware 288Geschäftsregeln 203Grenzen überschreiten 215Kopplung an verfrühte Entscheidungen

175testfähige Architektur erstellen 210und unabhängige Entwickelbarkeit 171

User Interface siehe GUI (Graphical User Interface)

Utility LibraryZone of Pain 146

uucp-Verbindung 345

Vvan Wijngaarden, Adriaan 52Variablen

funktionale Sprachen 75veränderbare 75, 76

Varian 620/f 315Veränderbare Variablen 75, 76Vererbung

objektorientierte Programmierung 63Vererbungsbeziehung

Abhängigkeitsmanagement 291Abhängigkeitsumkehr 70gesteuerte Nutzung 98Grenzen überschreiten 215objektorientierte Programmierung 70

Verfrühte EntscheidungenKopplung 175

Verhaltenals Systemwert 39Architektur vor Funktionalität 43Architektur vs. Funktionalität 41

Eisenhower-Prinzip 42Optionen offenhalten 157

Verklemmungen siehe DeadlocksVersehentliche Duplizierung 86, 171View Model

Presenters und Views 220Views

Komponentenarchitektur 290saubere Architektur 214und Presenters 220

Visual StudioPlug-in-Argument 186

Von-Neumann-Architekturen 67VT100-Terminal 331

WWartungsbedarf 327Web

Abhängigkeitsregel 214als Bereitstellungssystem für die Anwen-

dung 209Detail 279

Web als DetailFazit 282GUI (Graphical User Interface) 281Übersicht 279

Webserverals Option offenhalten 209eigenen schreiben 179in der Entwicklungsphase als Option

offenhalten 158testfähige Architektur erstellen 210

Wettlaufsituationen siehe Race ConditionsWhitesmiths 332Wichtigkeit

Eisenhower-Prinzip 42Wiederverwendbares Framework 351Wiederverwendbarkeit siehe CRP (Common-

Reuse-Prinzip)Wiederverwendbarkeit von Code 350Wiki-Text

architektonische Erfolgsgeschichte 179Wissenschaftliche Methode

Anweisungen widerlegen 55Wöchentlicher Build 130

XX Window System 344XML 344

YYourdon, Ed 55



373

ZZeiger 343

zur Erzeugung polymorphen Verhaltens 67

Zone of Pain 145Zone of Uselessness 146Zugriffsmodifikatoren

architektonische Packages 306Zustände

Speichern von Transaktionen ohne Zustände 78

ZustandsänderungenProbleme durch Nebenläufigkeit 75

Zuweisungfunktionale Programmierung 48

ZyklenAbhängigkeiten abschaffen 131durchbrechen 134im Komponentenabhängigkeitsgraphen

131Problemstellung beim wöchentlichen

Build 130Zyklus durchbrechen

Acyclic-Dependencies-Prinzip 134


Inhaltsverzeichnis · Inhaltsverzeichnis 10 22 Die saubere Architektur. . . . . . . . . . . . . . ....

Documents

Transcript of Inhaltsverzeichnis · Inhaltsverzeichnis 10 22 Die saubere Architektur. . . . . . . . . . . . . . ....