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...

Full description

Bibliographic Details
Main Author: Hombergs, Tom (-)
Format: eBook
Language:Alemán
Published: Frechen : mitp Verlags GmbH & Co.KG 2024.
Edition:1st ed
Subjects:
See on Biblioteca Universitat Ramon Llull:https://discovery.url.edu/permalink/34CSUC_URL/1im36ta/alma991009820528206719
Table of Contents:
  • 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.