
Domain-Driven Transformation
Description
Alles über E-Books | Antworten auf Fragen rund um E-Books, Kopierschutz und Dateiformate finden Sie in unserem Info- & Hilfebereich.
More details
Other editions
Additional editions


Persons
Content
- Cover
- Über den Autor
- Titel
- Impressum
- Vorwort
- Inhalt
- 1 Einleitung: Komplexität beherrschen
- 1.1 Komplexität
- 1.2 Herkunft der Komplexität: Problem- und Lösungsraum
- 1.3 Art der Komplexität: essenziell vs. akzidentell
- 1.3.1 Quellen akzidenteller Komplexität
- 1.3.2 Entscheidungsbereiche von Softwarearchitektur
- 1.4 Komplexität in Legacy-Systemen
- 1.5 Struktur dieses Buches
- Teil I Grundlagen für Domain-Driven Transformation
- 2 Domain-Driven Design
- 2.1 DDD-Konzepte gegen Komplexität
- 2.2 DDD und die Fachdomäne
- 2.2.1 Ubiquitous Language
- 2.2.1.1 Begriffsmodelle
- 2.2.1.2 Glossare
- 2.2.1.3 Verschmutzung der Fachsprache mit technischen Begriffen
- 2.2.1.4 Deutsch oder Englisch?
- 2.2.2 Strategisches Design in der Domäne
- 2.2.3 Subdomänen kategorisieren - was ist der Kern?
- 2.2.3.1 Core Domain
- 2.2.3.2 Generic und Supporting Subdomain
- 2.3 DDD und die Softwarelösung
- 2.3.1 Strategisches Design in der Technik
- 2.3.1.1 Bounded Context
- 2.3.1.2 Context Map
- 2.3.2 Context Mapping
- 2.3.2.1 Dimension »Zusammenarbeit zwischen den Teams«
- 2.3.2.2 Dimension »Technische Umsetzung der Schnittstelle«
- 2.3.3 Bubble Context
- 2.3.4 Das Domänenmodell
- 2.3.4.1 Domänenmodell im Kontext
- 2.3.4.2 Wiederverwendung, Duplikation und Redundanz
- 2.3.5 Die Schichtenarchitektur in DDD
- 2.3.6 Taktisches Design
- 2.3.7 Domain Events
- 2.4 Zusammenfassung
- 3 Collaborative Modeling
- 3.1 Die richtigen Leute zusammenbringen
- 3.2 Grundlegende Konzepte des Collaborative Modeling
- 3.3 Modellierungswerkzeuge und das Modellmonopol
- 3.4 Collaborative Modeling und DDD
- 3.5 Domain Storytelling
- 3.5.1 Ein Bild - eine Geschichte
- 3.5.2 Grenzen ziehen
- 3.5.3 Scope-Faktoren für Domain Stories
- 3.5.4 Das Domänenmodell finden
- 3.5.5 Ausblick
- 3.6 Event Storming
- 3.6.1 Storming-Phase
- 3.6.2 Zeitliche Ordnung herstellen
- 3.6.3 Grenzen ziehen
- 3.6.4 Die Farbcodierung
- 3.6.5 Tiefer ins Detail: Design Level Event Storming
- 3.6.6 Das Domänenmodell finden
- 3.6.7 Weitere Formate und Ausblick
- 3.7 Wann welche Methode einsetzen?
- 3.8 Collaborative Modeling Remote
- 3.9 Andere Techniken des Collaborative Modeling
- 3.10 Zusammenfassung
- 4 Architekturkonzepte
- 4.1 Modularität
- 4.2 Kohäsion und Kopplung
- 4.2.1 Kohäsion und Kopplung in der Fachlichkeit
- 4.3 Big Ball of Mud
- 4.3.1 Auf Klassenebene
- 4.3.2 Auf Architekturebene
- 4.3.3 Entstehen eines Big Ball of Mud
- 4.3.4 Kopplung und Wiederverwendung
- 4.4 Monolith
- 4.5 Microservices
- 4.6 Vom Monolithen zu Microservices
- 4.7 Die gute alte Schichtenarchitektur
- 4.8 Hexagonal Architecture und ihre Varianten: Onion, Clean und mehr
- 4.8.1 Verschiedene Stile zusammen - Explicit Architecture
- 4.8.2 Innen-außen-Architekturen und taktisches DDD
- 4.9 Software Architecture Hamburger
- 4.10 Serviceorientierte Architekturen (SOA)
- 4.11 Self-Contained Systems
- 4.12 Von IT-Landschaften zu SOA und wieder zurück
- 4.13 Der Modularity Maturity Index: Wo stehen Sie?
- 4.13.1 Modularität im MMI
- 4.13.2 Hierarchie im MMI
- 4.13.3 Musterkonsistenz im MMI
- 4.13.4 Beispielhafter MMI verschiedener Systeme
- 4.14 Zusammenfassung
- 5 Vorgehen klären
- 5.1 Der MMI und die Wege durch die Domain-Driven Transformation
- 5.1.1 Big Ball of Mud (MMI 0-4 - rot)
- 5.1.2 Technische Schichtenarchitektur (MMI 4-8 - gelb)
- 5.1.3 Fachliche Modularisierung (MMI 8-10 - grün)
- 5.2 Auswahl des Vorgehens
- 5.2.1 Ersetzen - Big Bang Replacement
- 5.2.2 Ersetzen - schrittweise Ablösung
- 5.2.3 Umformen
- 5.3 Zusammenfassung
- Teil II Technische, taktische und teamorganisatorische Domain-Driven Transformation
- 6 Legacy-Software technisch stabilisieren
- 6.1 Build und Deployment automatisieren
- 6.2 Verwendete Software aktualisieren
- 6.2.1 Abhängigkeiten aktualisieren
- 6.2.2 Die Programmiersprache aktualisieren
- 6.3 Testabdeckung beim Bugfixing erhöhen
- 6.3.1 Die Pfadfinderregel
- 6.3.2 Unterschiedliche Arten von Tests
- 6.4 Refactoring
- 6.4.1 Abhängigkeit aufbrechen
- 6.4.2 Compiler- und IDE-Warnungen auflösen
- 6.4.3 Interne Struktur anhand von Metriken verbessern
- 6.5 Fehlerrobustheit
- 6.5.1 Robustheit gegenüber null aufbauen
- 6.5.2 Einsatz von Exceptions glattziehen
- 6.5.3 Design by Contract einführen
- 6.6 Zusammenfassung
- 6.7 Wo stehen Sie?
- 7 Fachlichkeit stärken
- 7.1 Fachlichen und technischen Sourcecode trennen
- 7.2 Kohäsion erhöhen
- 7.2.1 Modellierung fachlich anreichern
- 7.2.2 Value Objects einsetzen
- 7.2.3 Design by Contract einführen
- 7.2.4 Identität von Entities explizit machen
- 7.3 Kopplung verringern
- 7.3.1 Zyklen und Abhängigkeiten auflösen
- 7.3.2 An Aggregate-Grenzen ID-Referenzen einführen
- 7.3.3 Vererbung im fachlichen Sourcecode reduzieren
- 7.3.4 Das Liskov Substitution Principle (LSP)
- 7.4 Architektur im Code dokumentieren
- 7.5 Zusammenfassung
- 7.6 Wo stehen Sie?
- 8 Teamorganisation verbessern
- 8.1 Software als soziotechnisches System
- 8.1.1 Architekturschnitt/Teamorganisation horizontal
- 8.1.1.1 Spezialfall Framework-Team
- 8.1.1.2 Probleme mit dem horizontalen Schnitt
- 8.1.2 Architekturschnitt/Teamorganisation vertikal
- 8.1.3 Wie führt man diese Teamreorganisation durch?
- 8.2 Team Topologies
- 8.2.1 Arbeiten im Flow
- 8.2.2 Arten von Topologien
- 8.2.3 Arten von Zusammenarbeit
- 8.2.4 Teamentwicklung in der Zeit
- 8.2.5 Architecture Modernization Enabling Teams
- 8.3 Zusammenfassung
- 8.4 Wo stehen Sie?
- Teil III Strategische Domain-Driven Transformation
- 9 Schritt 1 - Wiederentdecken der Fachdomäne
- 9.1 Schematische Beschreibung von Schritt 1
- 9.2 Herausforderung: Fachexperten bekommen
- 9.3 Herausforderung: Fachexperten auf die eigentliche Fachlichkeit zurückführen
- 9.4 Teilschritt 1.1: Kennenlernen der Ist-Situation
- 9.5 Teilschritt 1.2: Herausschälen der Fachlichkeit (Purifizieren)
- 9.5.1 Technik: Gedankenexperiment »Papierprozess«
- 9.5.2 Technik: Gedankenexperiment »Virtuelle Akteure«
- 9.5.3 Alternative: gleich pur modellieren
- 9.5.4 Ubiquitous Language destillieren
- 9.6 Teilschritt 1.3: Optimieren der Prozesse hin zu Soll-Prozessen
- 9.7 Teilschritt 1.4: Subdomänen im Arbeitsprozess finden
- 9.7.1 Indikatoren für Subdomänengrenzen
- 9.8 Herausforderung: Aufteilung der Subdomänen nicht nach Arbeitsgegenständen
- 9.9 Herausforderung: richtige Größe finden
- 9.9.1 Ziele der richtigen Größe
- 9.9.2 Indikatoren für die richtige Größe
- 9.10 Zusammenfassung
- 10 Schritt 2 - Modellierung der fachlichen Soll-Architektur
- 10.1 Schematische Beschreibung von Schritt 2
- 10.2 Teilschritt 2.1: Context Map erstellen
- 10.3 Herausforderung: Lösungsraum-induzierte Kontexte
- 10.4 Teilschritt 2.2: Subdomänen kategorisieren
- 10.5 Teilschritt 2.3: Kontexte an Teams zuteilen
- 10.6 Herausforderung: Teams zuordnen, heißt oft Teams formen
- 10.7 Teilschritt 2.4: Beziehungen bestimmen
- 10.8 Alles zusammen
- 10.9 Zusammenfassung
- 11 Schritt 3 - Abgleich Ist- mit Soll-Architektur
- 11.1 Schematische Beschreibung von Schritt 3
- 11.2 Teilschritt 3.1: Ist-Architektur ermitteln
- 11.3 Teilschritt 3.2: Soll-Context-Map auf den Sourcecode legen
- 11.4 Herausforderung: übergreifende Modelle
- 11.4.1 Zerlegung von innen nach außen
- 11.5 Herausforderung: das übergreifende Domänenmodell
- 11.5.1 Problemursache: Wiederverwendbarkeit missverstanden
- 11.6 Herausforderung: das übergreifende anämische Domänenmodell
- 11.7 Herausforderung: das übergreifende Datenmodell
- 11.8 Herausforderung: Zerlegen der Benutzungsoberfläche
- 11.8.1 Monolithische UI
- 11.8.2 UI im Kontext: Micro Frontends
- 11.9 Teilschritt 3.3: Refactorings und Findings zusammenstellen
- 11.10 Zusammenfassung
- 12 Schritt 4 - Priorisierung und Durchführung der Umbaumaßnahmen
- 12.1 Schematische Beschreibung von Schritt 4
- 12.2 Teilschritt 4.1: strategisches Refactoring auswählen
- 12.2.1 Muster: eine Supporting Domain zuerst
- 12.2.2 Muster: eine Core Domain als zweiten oder dritten Kontext
- 12.3 Teilschritt 4.2: taktische Refactorings ins Product Backlog eintragen
- 12.4 Teilschritt 4.3: leistbare Refactorings ins Sprint Backlog übertragen
- 12.4.1 Nur in Notfällen den Umbau ruhen lassen
- 12.4.2 Refactorings schätzen
- 12.4.3 Domain-Driven Transformation mit Kanban
- 12.5 Teilschritt 4.4: Kontext herauslösen
- 12.6 Herausforderung: Fachlogik in den Services entflechten
- 12.7 Herausforderung: lokale Daten, Setter und Getter in einen Kontext verschieben
- 12.7.1 Identität von Entities
- 12.8 Herausforderung: Daten, Setter und Getter in mehrere Kontexte duplizieren
- 12.9 Herausforderung: fachliche Domain Events zwischen Services einführen
- 12.10 Herausforderung: Fachlichkeit aus dem Service ins anämische Domänenmodell verschieben
- 12.10.1 Logik aus den Services in die anämischen Entities herunterdrücken
- 12.11 Herausforderung: Findings im geeigneten Moment auswählen
- 12.12 Herausforderung: den langen Atem behalten
- 12.13 Zusammenfassung
- Abschluss
- 13 Ausblick: Domain Patterns und ihre Umsetzung in Kontexten
- 13.1 Ebene 1: Arbeitsablauf in der Domäne
- 13.1.1 Domain Pattern »Pipeline«
- 13.1.2 Domain Pattern »Blackboard«
- 13.1.3 Domain Pattern »Dialog«
- 13.1.4 Entwicklung von Domain Patterns
- 13.2 Ebene 2: Das Domänenmodell in der Software
- 13.2.1 Zentrales Domänenobjekt vs. diverse Domänenobjekte
- 13.2.2 Formularbasiertes Domänenmodell
- 13.3 Ebene 3: Ausprägung der Domäne
- 13.3.1 Alter und Reife der Domäne
- 13.3.2 Gegenständliche Domäne vs. vollständig digitalisierte Domäne
- 13.3.3 Entwicklungspotenzial der Kontexte
- 13.4 Zusammenfassung
- 14 Fazit
- Fußnoten
- Anhang
- Literatur
- Index
System requirements
File format: PDF
Copy protection: Watermark-DRM (Digital Rights Management)
System requirements:
- Computer (Windows; MacOS X; Linux): Use the free software Adobe Reader, Adobe Digital Editions, or any other PDF viewer of your choice (see eBook Help).
- Tablet/Smartphone (Android; iOS): Install the free app Adobe Digital Editions or another reading app for eBooks, e.g., PocketBook (see eBook Help).
- E-reader: Bookeen, Kobo, Pocketbook, Sony, Tolino and many more (only limited: Kindle).
The file format PDF always displays a book page identically on any hardware. This makes PDF suitable for complex layouts such as those used in textbooks and reference books (images, tables, columns, footnotes). Unfortunately, on the small screens of e-readers or smartphones, PDFs are rather annoying, requiring too much scrolling.
This eBook uses Watermark-DRM, a „soft” copy protection. This means that there are no technical restrictions to prevent illegal distribution. However, there is a personalised watermark embedded in the eBook that can be used to identify the purchaser of the eBook in the event of misuse and to provide evidence for legal purposes.
For more information, see our eBook Help page.