Clean Architecture Praxisbuch
Description
- Best Practices für die Entwicklung von anpassungsfähiger Software
- Lernen Sie neue Konzepte kennen und verbinden Sie diese mit Ihrem eigenen Softwareentwicklungsstil
- Entwickeln Sie ein Mindset für bewusste Architekturentscheidungen
Der Weg zu wartbarer Software
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.
Domänen-zentrierte Architektur in der Praxis
Dieser umfassende Leitfaden zeigt die Vorteile domänen-zentrierter Softwarearchitektur auf - angelehnt an Robert C. Martins Clean Architecture und Alistair Cockburns hexagonale Architektur. Anhand zahlreicher Beispiele erfahren Sie, wie Sie eine hexagonale Architektur in Ihrem Code abbilden können. Sie lernen verschiedene Strategien für das Mapping zwischen den Schichten einer hexagonalen Architektur kennen und erfahren, wie Sie die Architekturelemente zu einer Anwendung zusammensetzen.
Komplexe Konzepte leicht verständlich erklärt
Mit anschaulichen Erläuterungen und anhand zahlreicher Codebeispiele schafft dieses Buch ein tiefes und praxistaugliches Verständnis des hexagonalen Architekturstils. So sind Sie perfekt darauf vorbereitet, wartbare Anwendungen zu erstellen, die Zeit und Geld sparen.
Aus dem Inhalt:
- Wartbare Software entwickeln
- Schwachstellen der herkömmlichen Schichtenarchitektur identifizieren
- Code sauber strukturieren
- Umkehren von Abhängigkeiten (Dependency Inversion)
- SOLID-Prinzipien für die hexagonale Architektur
- Use Cases implementieren
- Testmethoden für einzelne Architekturelemente
- Mapping-Strategien
- Architekturgrenzen durchsetzen
- Zahlreiche Codebeispiele in Java
Reviews / Votes
»Dieses Buch vermittelt Ihnen alle notwendigen Fähigkeiten und Kenntnisse, um wartbare und langlebige zu entwickeln, ohne Vorkenntnisse vorrauszusetzen.« (IT-Management, 07/24)
More details
Other editions
Additional editions
Person
Content
- 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
