Clean Architecture Praxisbuch : Für Saubere Software-Architekturen und Wartbaren Code. Mit Codebeispielen in Java.

Format:

Book

Author/Creator:

Hombergs, Tom.

Standardized Title:

Get your hands dirty on clean architecture. German

Language:

German

Subjects (All):

Software architecture.

Web applications.

Java (Computer program language).

Physical Description:

1 online resource (184 pages)

Edition:

1st ed.

Place of Publication:

Frechen : mitp Verlags GmbH & Co.KG, 2024.

Summary:

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

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.

Notes:

Description based on publisher supplied metadata and other sources.

Other Format:

Print version: Hombergs, Tom Clean Architecture Praxisbuch

ISBN:

9783747508169

OCLC:

1435901651