Clean Architecture Praxisbuch Für Saubere Software-Architekturen und Wartbaren Code. Mit Codebeispielen in Java
Eine wartungsfreundliche Architektur ist der Schlüssel, um Entwicklungsaufwand und -kosten niedrig zu halten. Dieses Buch vermittelt Ihnen alle notwendigen Fähigkeiten und Kenntnisse, um wartbare und langlebige Software zu entwickeln, ohne Vorkenntnisse vorauszusetzen. Dieser umfassende Leitfaden...
| Autor principal: | |
|---|---|
| Formato: | Libro electrónico |
| Idioma: | Alemán |
| Publicado: |
Frechen :
mitp Verlags GmbH & Co.KG
2024.
|
| Edición: | 1st ed |
| Materias: | |
| Ver en Biblioteca Universitat Ramon Llull: | https://discovery.url.edu/permalink/34CSUC_URL/1im36ta/alma991009820528206719 |
Tabla de Contenidos:
- Cover
- Titel
- Impressum
- Inhaltsverzeichnis
- Vorwort
- Mitwirkende
- Über den Autor
- Über die Fachgutachter
- Einleitung
- Das Ziel dieses Buches
- An wen sich dieses Buch richtet
- Die Beispielanwendung
- Treten Sie in Kontakt
- Kapitel 1: Wartbarkeit
- 1.1 Was bedeutet Wartbarkeit überhaupt?
- 1.2 Wartbarkeit führt zu Funktionalität
- 1.3 Wartbarkeit erzeugt Entwicklerfreude
- 1.4 Wartbarkeit unterstützt die Entscheidungsfindung
- 1.5 Die Wartbarkeit bewahren
- Kapitel 2: Was ist so falsch an Schichten?
- 2.1 Sie fördern ein datenbankgetriebenes Design
- 2.2 Sie sind anfällig für Abkürzungen
- 2.3 Sie werden immer schwieriger zu testen
- 2.4 Sie verbergen die Use Cases
- 2.5 Sie erschweren das parallele Arbeiten
- 2.6 Wie hilft Ihnen dies, wartbare Software zu entwickeln?
- Kapitel 3: Abhängigkeiten umkehren
- 3.1 Das Single-Responsibility-Prinzip
- 3.2 Eine Geschichte über Nebenwirkungen
- 3.3 Das Dependency-Inversion-Prinzip
- 3.4 Clean Architecture
- 3.5 Hexagonale Architektur
- 3.6 Wie hilft Ihnen dies, wartbare Software zu entwickeln?
- Kapitel 4: Code organisieren
- 4.1 Nach Schichten organisieren
- 4.2 Nach Features organisieren
- 4.3 Eine Architektur-explizite Paketstruktur
- 4.4 Die Rolle der Dependency Injection
- 4.5 Wie hilft Ihnen dies, wartbare Software zu entwickeln?
- Kapitel 5: Einen Use Case implementieren
- 5.1 Das Domänenmodell implementieren
- 5.2 Ein Use Case im Überblick
- 5.3 Die Eingabe validieren
- 5.4 Die Macht von Konstruktoren
- 5.5 Unterschiedliche Eingabemodelle für unterschiedliche Use Cases
- 5.6 Business-Regeln validieren
- 5.7 Reiches versus anämisches Domänenmodell
- 5.8 Unterschiedliche Ausgabemodelle für unterschiedliche Use Cases
- 5.9 Was ist mit »read only« Use Cases?
- 5.10 Wie hilft Ihnen dies, wartbare Software zu entwickeln?.
- Kapitel 6: Einen Web-Adapter implementieren
- 6.1 Dependency Inversion
- 6.2 Die Verantwortlichkeiten eines Web-Adapters
- 6.3 Wie hilft Ihnen dies, wartbare Software zu entwickeln?
- Kapitel 7: Einen Persistenz-Adapter implementieren
- 7.1 Dependency Inversion
- 7.2 Verantwortlichkeiten eines Persistenz-Adapters
- 7.3 Portschnittstellen aufteilen
- 7.4 Persistenz-Adapter aufteilen
- 7.5 Ein Beispiel mit Spring Data JPA
- 7.6 Was ist mit Datenbanktransaktionen?
- 7.7 Wie hilft Ihnen dies, wartbare Software zu entwickeln?
- Kapitel 8: Architekturelemente testen
- 8.1 Die Testpyramide
- 8.2 Testen eines Domänen-Entitys mit Unit-Tests
- 8.3 Testen eines Use Case mit Unit-Tests
- 8.4 Testen eines Web-Adapters mit Integrationstests
- 8.5 Testen eines Persistenz-Adapters mit Integrationstests
- 8.6 Testen der Hauptpfade mit Systemtests
- 8.7 Wie viel Testen ist genug?
- 8.8 Wie hilft Ihnen dies, wartbare Software zu entwickeln?
- Kapitel 9: Mapping über Grenzen hinweg
- 9.1 Die »No Mapping«-Strategie
- 9.2 Die »Zwei-Wege«-Mapping-Strategie
- 9.3 Die »vollständige« Mapping-Strategie
- 9.4 Die »Ein-Weg«-Mapping-Strategie
- 9.5 Wann wird welche Mapping-Strategie benutzt?
- 9.6 Wie hilft Ihnen dies, wartbare Software zu entwickeln?
- Kapitel 10: Die Anwendung zusammensetzen
- 10.1 Warum ist das Zusammensetzen wichtig?
- 10.2 Konfiguration mit einfachem Code
- 10.3 Konfiguration mit Classpath-Scanning von Spring
- 10.4 Konfiguration mit Java Config von Spring
- 10.5 Wie hilft Ihnen dies, wartbare Software zu entwickeln?
- Kapitel 11: Bewusst Abkürzungen nehmen
- 11.1 Wieso Abkürzungen wie eingeschlagene Fenster sind
- 11.2 Die Verantwortung, sauber zu beginnen
- 11.3 Modelle zwischen Use Cases teilen
- 11.4 Domänen-Entities als Ein- oder Ausgabemodell benutzen
- 11.5 Eingangsports überspringen
- 11.6 Services überspringen.
- 11.7 Wie hilft Ihnen dies, wartbare Software zu entwickeln?
- Kapitel 12: Architekturgrenzen erzwingen
- 12.1 Grenzen und Abhängigkeiten
- 12.2 Modifier für die Sichtbarkeit
- 12.3 Fitnessfunktion nach dem Kompilieren
- 12.4 Build-Artefakte
- 12.5 Wie hilft Ihnen dies, wartbare Software zu entwickeln?
- Kapitel 13: Mehrere Bounded Contexts verwalten
- 13.1 Ein Hexagon pro Bounded Context?
- 13.2 Entkoppelte Bounded Contexts
- 13.3 Angemessen gekoppelte Bounded Contexts
- 13.4 Wie hilft Ihnen dies, wartbare Software zu entwickeln?
- Kapitel 14: Ein komponentenbasierter Ansatz für die Softwarearchitektur
- 14.1 Modularität durch Komponenten
- 14.2 Fallstudie - eine »Check Engine«-Komponente erstellen
- 14.3 Komponentengrenzen validieren
- 14.4 Wie hilft Ihnen dies, wartbare Software zu entwickeln?
- Kapitel 15: Sich für einen Architekturstil entscheiden
- 15.1 Beginnen Sie einfach
- 15.2 Entwickeln Sie die Domäne
- 15.3 Vertrauen Sie auf Ihre Erfahrung
- 15.4 Es kommt drauf an
- Stichwortverzeichnis.
