Clean Architecture (mitp Professional) by Martin, Robert C. -- Read -- Imperial Library of Trantor

Index

Impressum Vorwort Einleitung Über den Autor Danksagung Teil I: Einführung Kapitel 1: Was bedeuten »Design« und »Architektur«?‌

1.1 Das Ziel‌? 1.2 Fallstudie

1.2.1 Die Signatur des Chaos‌‌ 1.2.2 Die Perspektive der Unternehmensleitung 1.2.3 Was ist schiefgelaufen?

1.3 Fazit‌

Kapitel 2: Die Geschichte zweier Werte‌

2.1 Verhalten‌ 2.2 Architektur‌‌ 2.3 Der größere Wert 2.4 Das Eisenhower-Prinzip‌‌‌‌ 2.5 Der Kampf für die Architektur‌‌‌‌

Teil II: Die ersten Bausteine setzen: Programmierparadigmen‌‌ Kapitel 3: Die Paradigmen‌

3.1 Strukturierte Programmierung‌‌ 3.2 Objektorientierte Programmierung‌ 3.3 Funktionale Programmierung‌ 3.4 Denkanstöße 3.5 Fazit‌

Kapitel 4: Strukturierte Programmierung‌

4.1 Die Beweisführung‌‌ 4.2 Eine »schädliche« Proklamation‌‌ 4.3 Funktionale Dekomposition‌‌ 4.4 Keine formalen Beweise 4.5 Wissenschaft‌ als Rettung 4.6 Tests‌‌ 4.7 Fazit‌

Kapitel 5: Objektorientierte Programmierung‌

5.1 Datenkapselung‌‌? 5.2 Vererbung‌‌? 5.3 Polymorphie‌‌

5.3.1 Die Macht der Polymorphie‌‌ 5.3.2 Abhängigkeitsumkehr‌‌‌

5.4 Fazit‌

Kapitel 6: Funktionale Programmierung‌

6.1 Quadrierung von Integern‌‌ 6.2 Unveränderbarkeit‌‌ und Architektur‌ 6.3 Unterteilung der Veränderbarkeit‌ 6.4 Event Sourcing‌ 6.5 Fazit‌

Teil III: Designprinzipien‌ Kapitel 7: SRP: Das Single-Responsibility-Prinzip‌

7.1 Symptom 1: Versehentliche Duplizierung‌‌‌ 7.2 Symptom 2: Merges‌‌ 7.3 Lösungen‌ 7.4 Fazit‌

Kapitel 8: OCP: Das Open-Closed-Prinzip‌

8.1 Ein Gedankenexperiment‌ 8.2 Richtungssteuerung‌‌ 8.3 Information Hiding‌‌‌ 8.4 Fazit‌

Kapitel 9: LSP: Das Liskov’sche Substitutionsprinzip‌

9.1 Gesteuerte Nutzung der Vererbung‌‌‌ 9.2 Das Quadrat-Rechteck-Problem‌‌ 9.3 Das LSP und die Softwarearchitektur‌‌ 9.4 Beispiel für einen Verstoß gegen das LSP‌ 9.5 Fazit‌

Kapitel 10: ISP: Das Interface-Segregation-Prinzip‌

10.1 Das ISP und die Programmiersprachen‌‌ 10.2 Das ISP und die Softwarearchitektur‌‌ 10.3 Fazit‌

Kapitel 11: DIP: Das Dependency-Inversion-Prinzip‌

11.1 Stabile Abstraktionen‌‌ 11.2 Factories‌ 11.3 Konkrete Komponenten‌‌‌ 11.4 Fazit‌

Teil IV: Komponentenprinzipien‌ Kapitel 12: Komponenten‌

12.1 Eine kurze Historie der Komponenten‌ 12.2 Relokatierbarkeit‌ 12.3 Linker‌ 12.4 Fazit‌

Kapitel 13: Komponentenkohäsion‌

13.1 REP: Das Reuse-Release-Equivalence-Prinzip‌‌ 13.2 CCP: Das Common-Closure-Prinzip‌‌

13.2.1 Ähnlichkeiten mit dem SRP‌

13.3 CRP: Das Common-Reuse-Prinzip‌‌

13.3.1 Relation zum ISP‌

13.4 Das Spannungsdiagramm für die Komponentenkohäsion‌ 13.5 Fazit‌

Kapitel 14: Komponentenkopplung‌‌‌

14.1 ADP: Das Acyclic-Dependencies-Prinzip‌‌

14.1.1 Der wöchentliche Build‌‌‌‌ 14.1.2 Abhängigkeitszyklen abschaffen‌‌ 14.1.3 Auswirkung eines Zyklus in einem Komponentenabhängigkeitsgraphen‌‌ 14.1.4 Den Zyklus durchbrechen‌‌‌ 14.1.5 Jitters (Fluktuationen)‌‌

14.2 Top-down-Design‌‌ 14.3 SDP: Das Stable-Dependencies-Prinzip‌‌‌‌

14.3.1 Stabilität 14.3.2 Stabilitätsmetriken‌‌‌‌ 14.3.3 Nicht alle Komponenten sollten stabil sein‌‌ 14.3.4 Abstrakte Komponenten‌‌‌

14.4 SAP: Das Stable-Abstractions-Prinzip‌

14.4.1 Wo werden die übergeordneten Richtlinien hinterlegt?‌‌ 14.4.2 Einführung in das SAP (Stable-Abstractions-Prinzip)‌‌ 14.4.3 Bemessung der Abstraktion‌‌ 14.4.4 Die Hauptreihe‌‌‌ 14.4.5 Die »Zone of Pain‌« 14.4.6 Die »Zone of Uselessness‌‌« 14.4.7 Die Ausschlusszonen vermeiden‌‌‌ 14.4.8 Abstand von der Hauptreihe‌‌‌

14.5 Fazit‌‌

Teil V: Softwarearchitektur Kapitel 15: Was ist Softwarearchitektur?

15.1 Entwicklung‌‌ 15.2 Deployment‌‌ 15.3 Betrieb‌ 15.4 Instandhaltung‌ 15.5 Optionen offenhalten‌ 15.6 Geräteunabhängigkeit‌‌‌ 15.7 Junk Mail‌‌‌ 15.8 Physische Adressierung‌‌‌ 15.9 Fazit‌

Kapitel 16: Unabhängigkeit‌‌

16.1 Use Cases‌‌‌ 16.2 Betrieb‌‌ 16.3 Entwicklung‌‌ 16.4 Deployment‌‌ 16.5 Optionen offenhalten‌‌‌ 16.6 Layer entkoppeln‌‌‌ 16.7 Use Cases entkoppeln‌‌‌ 16.8 Entkopplungsmodi‌‌ 16.9 Unabhängige Entwickelbarkeit‌‌‌‌‌ 16.10 Unabhängige Deploybarkeit‌‌‌ 16.11 Duplizierung‌‌‌ 16.12 Entkopplungsmodi‌‌ (zum Zweiten)

16.12.1 Welcher Modus ist am besten geeignet?

16.13 Fazit‌

Kapitel 17: Grenzen‌: Linien ziehen

17.1 Ein paar traurige Geschichten‌ 17.2 FitNesse‌ 17.3 Welche Grenzen sollten Sie ziehen – und wann‌? 17.4 Wie verhält es sich mit der Ein- und Ausgabe‌? 17.5 Plug-in-Architektur‌‌‌ 17.6 Das Plug-in-Argument‌ 17.7 Fazit‌

Kapitel 18: Anatomie der Grenzen‌

18.1 Grenzüberschreitungen‌ 18.2 Der gefürchtete Monolith‌ 18.3 Deployment-Komponenten‌‌ 18.4 Threads‌ 18.5 Lokale Prozesse‌‌ 18.6 Services‌ 18.7 Fazit‌

Kapitel 19: Richtlinien‌ und Ebenen‌

19.1 Ebene 19.2 Fazit‌

Kapitel 20: Geschäftsregeln‌

20.1 Entitäten‌‌‌ 20.2 Use Cases‌‌ 20.3 Request-and-Response-Modelle‌‌‌ 20.4 Fazit‌

Kapitel 21: Die schreiende Softwarearchitektur‌

21.1 Das Thema einer Architektur‌ 21.2 Der Zweck einer Softwarearchitektur‌‌ 21.3 Aber was ist mit dem Web‌‌? 21.4 Frameworks sind Tools, keine Lebenseinstellung‌‌ 21.5 Testfähige Architekturen‌‌ 21.6 Fazit‌

Kapitel 22: Die saubere Architektur‌

22.1 Die Abhängigkeitsregel‌‌‌ (Dependency Rule)

22.1.1 Entitäten‌‌ 22.1.2 Use Cases‌‌ 22.1.3 Schnittstellenadapter‌‌ 22.1.4 Frameworks und Treiber‌‌‌‌ 22.1.5 Nur vier Kreise? 22.1.6 Grenzen überschreiten‌‌‌ 22.1.7 Welche Daten überqueren die Grenzlinien‌‌‌?

22.2 Ein typisches Beispiel‌ 22.3 Fazit‌

Kapitel 23: Presenters und »Humble Objects«‌‌

23.1 Das Pattern »Humble Object« 23.2 Presenters und Views‌‌‌‌ 23.3 Das Testen und die Softwarearchitektur‌‌‌‌ 23.4 Datenbank-Gateways‌‌‌‌ 23.5 Data Mappers‌‌‌ 23.6 Service Listeners‌‌ 23.7 Fazit‌

Kapitel 24: Partielle Grenzen‌‌

24.1 Den letzten Schritt weglassen‌ 24.2 Eindimensionale Grenzen‌‌‌ 24.3 Fassaden‌ 24.4 Fazit‌

Kapitel 25: Layer und Grenzen‌

25.1 Hunt the Wumpus 25.2 Saubere Architektur‌‌? 25.3 Datenstromüberschreitungen‌‌ 25.4 Datenströme teilen‌‌‌‌ 25.5 Fazit‌

Kapitel 26: Die Komponente Main‌

26.1 Das ultimative Detail‌ 26.2 Fazit‌

Kapitel 27: Services‌ – große und kleine

27.1 Servicearchitektur‌? 27.2 Vorteile der Services‌?

27.2.1 Denkfalle: Entkopplung‌‌‌‌ 27.2.2 Denkfalle: Unabhängige Entwickel- und Deploybarkeit‌‌‌

27.3 Das Kätzchen-Problem‌‌‌‌‌‌ 27.4 Objekte als Rettung‌‌‌‌‌ 27.5 Komponentenbasierte Services‌ 27.6 Cross-Cutting Concerns 27.7 Fazit‌

Kapitel 28: Die Testgrenze‌

28.1 Tests als Systemkomponenten‌‌ 28.2 Design für Testfähigkeit‌‌‌ 28.3 Die Test-API‌‌

28.3.1 Strukturelle Kopplung‌ 28.3.2 Sicherheit

28.4 Fazit‌

Kapitel 29: Saubere eingebettete Architektur‌

29.1 App-Eignungstest‌‌ 29.2 Der Flaschenhals der Zielhardware‌‌

29.2.1 Eine saubere eingebettete Architektur ist eine testfähige eingebettete Architektur‌‌ 29.2.2 Offenbaren Sie dem HAL-User keine Hardwaredetails‌‌‌

29.3 Fazit‌

Teil VI: Details Kapitel 30: Die Datenbank ist ein Detail‌‌‌

30.1 Relationale Datenbanken‌ 30.2 Warum sind Datenbanksysteme so weit verbreitet?‌‌ 30.3 Was wäre, wenn es keine Festplatten gäbe?‌‌ 30.4 Details‌ 30.5 Und was ist mit der Performance‌‌? 30.6 Anekdote‌ 30.7 Fazit‌

Kapitel 31: Das Web ist ein Detail‌‌‌

31.1 Der immerwährende Pendelausschlag 31.2 Quintessenz 31.3 Fazit‌

Kapitel 32: Ein Framework ist ein Detail‌‌‌

32.1 Framework-Autoren‌‌ 32.2 Asymmetrische Ehe‌ 32.3 Die Risiken‌‌ 32.4 Die Lösung‌ 32.5 Hiermit erkläre ich euch zu ... 32.6 Fazit‌

Kapitel 33: Fallstudie: Software‌ für den Verkauf von Videos

33.1 Das Produkt‌‌ 33.2 Use-Case-Analyse‌‌ 33.3 Komponentenarchitektur‌‌ 33.4 Abhängigkeitsmanagement‌‌‌‌ 33.5 Fazit‌

Kapitel 34: Das fehlende Kapitel‌

34.1 Package by Layer‌‌ 34.2 Package by Feature‌‌ 34.3 Ports and Adapters‌ 34.4 Package by Component‌ 34.5 Der Teufel steckt in den Implementierungsdetails‌ 34.6 Organisation vs. Kapselung‌‌‌ 34.7 Andere Entkopplungsmodi‌ 34.8 Fazit: Der fehlende Ratschlag

Anhang A: Architekturarchäologie

A.1 Das Buchhaltungssystem für die Gewerkschaft A.2 Zurechtschneiden mit dem Laser A.3 Monitoring von Aluminiumspritzguss A.4 4-TEL

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

A.5 Die Programmiersprache C

A.5.1 C

A.6 BOSS A.7 Projekt CCU

A.7.1 Denkfalle: Die Planung

A.8 DLU/DRU

A.8.1 Architektur

A.9 VRS

A.9.1 Der Name A.9.2 Architektur A.9.3 VRS: Fazit

A.10 Der Elektronische Rezeptionist

A.10.1 Der Untergang des ER

A.11 Craft Dispatch System A.12 Clear Communications

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

A.13 ROSE

A.13.1 Fortsetzung der Debatten ... A.13.2 ... unter anderem Namen

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

Anhang B: Nachwort

← Prev
Back
Next →

← Prev
Back
Next →