Domain-Driven Transformation

Domain-Driven Transformation

by Carola Lilienthal, Henning Schwentner
Released August 2023
Publisher(s): dpunkt
ISBN: 9783864908842

Read it now on the O’Reilly learning platform with a 10-day free trial.

O’Reilly members get unlimited access to books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial

Book description

In den letzten Jahrzehnten wurde viel Software entwickelt, die wir heute modernisieren und zukunftsfähig machen müssen. Carola Lilienthal und Henning Schwentner haben in den vergangenen Jahren umfassende Erfahrungen gesammelt, wie sich Domain-Driven Design (DDD) einsetzen lässt, um große Legacy- Systeme in Microservices zu zerlegen oder zu wartbaren Monolithen umzubauen.Mit ihrer Methode »Domain-Driven Transformation« haben sie einen umfassenden Ansatz geschaffen, um sowohl auf strategischer als auch auf technischer und teamorganisatorischer Ebene architektonisch erodierte Softwaresysteme zu transformieren. Dabei spannen sie den Bogen von der Analyse der fachlichen Prozesse und der Zerlegung in Bounded Contexts bis hin zu Domain-Driven Refactorings und deren Umsetzung in agilen Teams. Schließlich geben sie der Leserschaft eine Anleitung, wie der Transformationsprozess abhängig vom Zustand der vorhandenen Architektur gestaltet werden sollte. Im Einzelnen werden behandelt:- Domain-Driven Design- Collaborative Modeling- Team Topologies- Microservices und Monolithen- Modularity Maturity Index (MMI)- Domain-Driven Refactorings- Priorisierung und Durchführung der UmbaumaßnahmenSie lernen anhand zahlreicher Beispiele verschiedene Möglichkeiten der Transformation bis hinunter in den Code kennen, die Sie schrittweise in Ihre Alltagspraxis übernehmen können, um die Wartbarkeit Ihrer Legacy- Systeme effektiv und schnell zu verbessern.

Table of contents

  1. Cover
  2. Über den Autor
  3. Titel
  4. Impressum
  5. Vorwort
  6. Inhalt
  7. 1 Einleitung: Komplexität beherrschen
    1. 1.1 Komplexität
    2. 1.2 Herkunft der Komplexität: Problem- und Lösungsraum
    3. 1.3 Art der Komplexität: essenziell vs. akzidentell
    4. 1.3.1 Quellen akzidenteller Komplexität
    5. 1.3.2 Entscheidungsbereiche von Softwarearchitektur
    6. 1.4 Komplexität in Legacy-Systemen
    7. 1.5 Struktur dieses Buches
  8. Teil I Grundlagen für Domain-Driven Transformation
    1. 2 Domain-Driven Design
    2. 2.1 DDD-Konzepte gegen Komplexität
    3. 2.2 DDD und die Fachdomäne
    4. 2.2.1 Ubiquitous Language
    5. 2.2.1.1 Begriffsmodelle
    6. 2.2.1.2 Glossare
    7. 2.2.1.3 Verschmutzung der Fachsprache mit technischen Begriffen
    8. 2.2.1.4 Deutsch oder Englisch?
    9. 2.2.2 Strategisches Design in der Domäne
    10. 2.2.3 Subdomänen kategorisieren – was ist der Kern?
    11. 2.2.3.1 Core Domain
    12. 2.2.3.2 Generic und Supporting Subdomain
    13. 2.3 DDD und die Softwarelösung
    14. 2.3.1 Strategisches Design in der Technik
    15. 2.3.1.1 Bounded Context
    16. 2.3.1.2 Context Map
    17. 2.3.2 Context Mapping
    18. 2.3.2.1 Dimension »Zusammenarbeit zwischen den Teams«
    19. 2.3.2.2 Dimension »Technische Umsetzung der Schnittstelle«
    20. 2.3.3 Bubble Context
    21. 2.3.4 Das Domänenmodell
    22. 2.3.4.1 Domänenmodell im Kontext
    23. 2.3.4.2 Wiederverwendung, Duplikation und Redundanz
    24. 2.3.5 Die Schichtenarchitektur in DDD
    25. 2.3.6 Taktisches Design
    26. 2.3.7 Domain Events
    27. 2.4 Zusammenfassung
    28. 3 Collaborative Modeling
    29. 3.1 Die richtigen Leute zusammenbringen
    30. 3.2 Grundlegende Konzepte des Collaborative Modeling
    31. 3.3 Modellierungswerkzeuge und das Modellmonopol
    32. 3.4 Collaborative Modeling und DDD
    33. 3.5 Domain Storytelling
    34. 3.5.1 Ein Bild – eine Geschichte
    35. 3.5.2 Grenzen ziehen
    36. 3.5.3 Scope-Faktoren für Domain Stories
    37. 3.5.4 Das Domänenmodell finden
    38. 3.5.5 Ausblick
    39. 3.6 Event Storming
    40. 3.6.1 Storming-Phase
    41. 3.6.2 Zeitliche Ordnung herstellen
    42. 3.6.3 Grenzen ziehen
    43. 3.6.4 Die Farbcodierung
    44. 3.6.5 Tiefer ins Detail: Design Level Event Storming
    45. 3.6.6 Das Domänenmodell finden
    46. 3.6.7 Weitere Formate und Ausblick
    47. 3.7 Wann welche Methode einsetzen?
    48. 3.8 Collaborative Modeling Remote
    49. 3.9 Andere Techniken des Collaborative Modeling
    50. 3.10 Zusammenfassung
    51. 4 Architekturkonzepte
    52. 4.1 Modularität
    53. 4.2 Kohäsion und Kopplung
    54. 4.2.1 Kohäsion und Kopplung in der Fachlichkeit
    55. 4.3 Big Ball of Mud
    56. 4.3.1 Auf Klassenebene
    57. 4.3.2 Auf Architekturebene
    58. 4.3.3 Entstehen eines Big Ball of Mud
    59. 4.3.4 Kopplung und Wiederverwendung
    60. 4.4 Monolith
    61. 4.5 Microservices
    62. 4.6 Vom Monolithen zu Microservices
    63. 4.7 Die gute alte Schichtenarchitektur
    64. 4.8 Hexagonal Architecture und ihre Varianten: Onion, Clean und mehr
    65. 4.8.1 Verschiedene Stile zusammen – Explicit Architecture
    66. 4.8.2 Innen-außen-Architekturen und taktisches DDD
    67. 4.9 Software Architecture Hamburger
    68. 4.10 Serviceorientierte Architekturen (SOA)
    69. 4.11 Self-Contained Systems
    70. 4.12 Von IT-Landschaften zu SOA und wieder zurück
    71. 4.13 Der Modularity Maturity Index: Wo stehen Sie?
    72. 4.13.1 Modularität im MMI
    73. 4.13.2 Hierarchie im MMI
    74. 4.13.3 Musterkonsistenz im MMI
    75. 4.13.4 Beispielhafter MMI verschiedener Systeme
    76. 4.14 Zusammenfassung
    77. 5 Vorgehen klären
    78. 5.1 Der MMI und die Wege durch die Domain-Driven Transformation
    79. 5.1.1 Big Ball of Mud (MMI 0–4 – rot)
    80. 5.1.2 Technische Schichtenarchitektur (MMI 4–8 – gelb)
    81. 5.1.3 Fachliche Modularisierung (MMI 8–10 – grün)
    82. 5.2 Auswahl des Vorgehens
    83. 5.2.1 Ersetzen – Big Bang Replacement
    84. 5.2.2 Ersetzen – schrittweise Ablösung
    85. 5.2.3 Umformen
    86. 5.3 Zusammenfassung
  9. Teil II Technische, taktische und teamorganisatorische Domain-Driven Transformation
    1. 6 Legacy-Software technisch stabilisieren
    2. 6.1 Build und Deployment automatisieren
    3. 6.2 Verwendete Software aktualisieren
    4. 6.2.1 Abhängigkeiten aktualisieren
    5. 6.2.2 Die Programmiersprache aktualisieren
    6. 6.3 Testabdeckung beim Bugfixing erhöhen
    7. 6.3.1 Die Pfadfinderregel
    8. 6.3.2 Unterschiedliche Arten von Tests
    9. 6.4 Refactoring
    10. 6.4.1 Abhängigkeit aufbrechen
    11. 6.4.2 Compiler- und IDE-Warnungen auflösen
    12. 6.4.3 Interne Struktur anhand von Metriken verbessern
    13. 6.5 Fehlerrobustheit
    14. 6.5.1 Robustheit gegenüber null aufbauen
    15. 6.5.2 Einsatz von Exceptions glattziehen
    16. 6.5.3 Design by Contract einführen
    17. 6.6 Zusammenfassung
    18. 6.7 Wo stehen Sie?
    19. 7 Fachlichkeit stärken
    20. 7.1 Fachlichen und technischen Sourcecode trennen
    21. 7.2 Kohäsion erhöhen
    22. 7.2.1 Modellierung fachlich anreichern
    23. 7.2.2 Value Objects einsetzen
    24. 7.2.3 Design by Contract einführen
    25. 7.2.4 Identität von Entities explizit machen
    26. 7.3 Kopplung verringern
    27. 7.3.1 Zyklen und Abhängigkeiten auflösen
    28. 7.3.2 An Aggregate-Grenzen ID-Referenzen einführen
    29. 7.3.3 Vererbung im fachlichen Sourcecode reduzieren
    30. 7.3.4 Das Liskov Substitution Principle (LSP)
    31. 7.4 Architektur im Code dokumentieren
    32. 7.5 Zusammenfassung
    33. 7.6 Wo stehen Sie?
    34. 8 Teamorganisation verbessern
    35. 8.1 Software als soziotechnisches System
    36. 8.1.1 Architekturschnitt/Teamorganisation horizontal
    37. 8.1.1.1 Spezialfall Framework-Team
    38. 8.1.1.2 Probleme mit dem horizontalen Schnitt
    39. 8.1.2 Architekturschnitt/Teamorganisation vertikal
    40. 8.1.3 Wie führt man diese Teamreorganisation durch?
    41. 8.2 Team Topologies
    42. 8.2.1 Arbeiten im Flow
    43. 8.2.2 Arten von Topologien
    44. 8.2.3 Arten von Zusammenarbeit
    45. 8.2.4 Teamentwicklung in der Zeit
    46. 8.2.5 Architecture Modernization Enabling Teams
    47. 8.3 Zusammenfassung
    48. 8.4 Wo stehen Sie?
  10. Teil III Strategische Domain-Driven Transformation
    1. 9 Schritt 1 – Wiederentdecken der Fachdomäne
    2. 9.1 Schematische Beschreibung von Schritt 1
    3. 9.2 Herausforderung: Fachexperten bekommen
    4. 9.3 Herausforderung: Fachexperten auf die eigentliche Fachlichkeit zurückführen
    5. 9.4 Teilschritt 1.1: Kennenlernen der Ist-Situation
    6. 9.5 Teilschritt 1.2: Herausschälen der Fachlichkeit (Purifizieren)
    7. 9.5.1 Technik: Gedankenexperiment »Papierprozess«
    8. 9.5.2 Technik: Gedankenexperiment »Virtuelle Akteure«
    9. 9.5.3 Alternative: gleich pur modellieren
    10. 9.5.4 Ubiquitous Language destillieren
    11. 9.6 Teilschritt 1.3: Optimieren der Prozesse hin zu Soll-Prozessen
    12. 9.7 Teilschritt 1.4: Subdomänen im Arbeitsprozess finden
    13. 9.7.1 Indikatoren für Subdomänengrenzen
    14. 9.8 Herausforderung: Aufteilung der Subdomänen nicht nach Arbeitsgegenständen
    15. 9.9 Herausforderung: richtige Größe finden
    16. 9.9.1 Ziele der richtigen Größe
    17. 9.9.2 Indikatoren für die richtige Größe
    18. 9.10 Zusammenfassung
    19. 10 Schritt 2 – Modellierung der fachlichen Soll-Architektur
    20. 10.1 Schematische Beschreibung von Schritt 2
    21. 10.2 Teilschritt 2.1: Context Map erstellen
    22. 10.3 Herausforderung: Lösungsraum-induzierte Kontexte
    23. 10.4 Teilschritt 2.2: Subdomänen kategorisieren
    24. 10.5 Teilschritt 2.3: Kontexte an Teams zuteilen
    25. 10.6 Herausforderung: Teams zuordnen, heißt oft Teams formen
    26. 10.7 Teilschritt 2.4: Beziehungen bestimmen
    27. 10.8 Alles zusammen
    28. 10.9 Zusammenfassung
    29. 11 Schritt 3 – Abgleich Ist- mit Soll-Architektur
    30. 11.1 Schematische Beschreibung von Schritt 3
    31. 11.2 Teilschritt 3.1: Ist-Architektur ermitteln
    32. 11.3 Teilschritt 3.2: Soll-Context-Map auf den Sourcecode legen
    33. 11.4 Herausforderung: übergreifende Modelle
    34. 11.4.1 Zerlegung von innen nach außen
    35. 11.5 Herausforderung: das übergreifende Domänenmodell
    36. 11.5.1 Problemursache: Wiederverwendbarkeit missverstanden
    37. 11.6 Herausforderung: das übergreifende anämische Domänenmodell
    38. 11.7 Herausforderung: das übergreifende Datenmodell
    39. 11.8 Herausforderung: Zerlegen der Benutzungsoberfläche
    40. 11.8.1 Monolithische UI
    41. 11.8.2 UI im Kontext: Micro Frontends
    42. 11.9 Teilschritt 3.3: Refactorings und Findings zusammenstellen
    43. 11.10 Zusammenfassung
    44. 12 Schritt 4 – Priorisierung und Durchführung der Umbaumaßnahmen
    45. 12.1 Schematische Beschreibung von Schritt 4
    46. 12.2 Teilschritt 4.1: strategisches Refactoring auswählen
    47. 12.2.1 Muster: eine Supporting Domain zuerst
    48. 12.2.2 Muster: eine Core Domain als zweiten oder dritten Kontext
    49. 12.3 Teilschritt 4.2: taktische Refactorings ins Product Backlog eintragen
    50. 12.4 Teilschritt 4.3: leistbare Refactorings ins Sprint Backlog übertragen
    51. 12.4.1 Nur in Notfällen den Umbau ruhen lassen
    52. 12.4.2 Refactorings schätzen
    53. 12.4.3 Domain-Driven Transformation mit Kanban
    54. 12.5 Teilschritt 4.4: Kontext herauslösen
    55. 12.6 Herausforderung: Fachlogik in den Services entflechten
    56. 12.7 Herausforderung: lokale Daten, Setter und Getter in einen Kontext verschieben
    57. 12.7.1 Identität von Entities
    58. 12.8 Herausforderung: Daten, Setter und Getter in mehrere Kontexte duplizieren
    59. 12.9 Herausforderung: fachliche Domain Events zwischen Services einführen
    60. 12.10 Herausforderung: Fachlichkeit aus dem Service ins anämische Domänenmodell verschieben
    61. 12.10.1 Logik aus den Services in die anämischen Entities herunterdrücken
    62. 12.11 Herausforderung: Findings im geeigneten Moment auswählen
    63. 12.12 Herausforderung: den langen Atem behalten
    64. 12.13 Zusammenfassung
  11. Abschluss
    1. 13 Ausblick: Domain Patterns und ihre Umsetzung in Kontexten
    2. 13.1 Ebene 1: Arbeitsablauf in der Domäne
    3. 13.1.1 Domain Pattern »Pipeline«
    4. 13.1.2 Domain Pattern »Blackboard«
    5. 13.1.3 Domain Pattern »Dialog«
    6. 13.1.4 Entwicklung von Domain Patterns
    7. 13.2 Ebene 2: Das Domänenmodell in der Software
    8. 13.2.1 Zentrales Domänenobjekt vs. diverse Domänenobjekte
    9. 13.2.2 Formularbasiertes Domänenmodell
    10. 13.3 Ebene 3: Ausprägung der Domäne
    11. 13.3.1 Alter und Reife der Domäne
    12. 13.3.2 Gegenständliche Domäne vs. vollständig digitalisierte Domäne
    13. 13.3.3 Entwicklungspotenzial der Kontexte
    14. 13.4 Zusammenfassung
    15. 14 Fazit
  12. Fußnoten
  13. Anhang
  14. Literatur
  15. Index

Product information

  • Title: Domain-Driven Transformation
  • Author(s): Carola Lilienthal, Henning Schwentner
  • Release date: August 2023
  • Publisher(s): dpunkt
  • ISBN: 9783864908842