Domain-Driven Design (DDD) Schulung: Event Storming, Contexts

Einführung in Domain-Driven Design

• Was Domain-Driven Design ist: Software entlang des fachlichen Modells strukturieren
• Herkunft des Ansatzes: Eric Evans' Buch von 2003, Vaughn Vernon und die DDD-Community
• Philosophie: Fachexpert:innen und Entwicklung arbeiten fortlaufend am selben Modell
• Unterschied zum datenbankgetriebenen Entwurf und zum reinen Schichtenmodell
• Wann sich der Aufwand lohnt: komplexe Fachregeln statt reiner Datenpflege
• DDD in Scrum und Kanban: Modellierung als laufende Arbeit im Backlog, nicht als Vorphase

Strategisches Design

• Problemraum und Lösungsraum: Domäne, Subdomänen und ihre Domänenmodelle
• Core, Supporting und Generic Subdomain: wo Eigenentwicklung lohnt, wo Standardsoftware reicht
• Bounded Context als Geltungsbereich eines Modells und seiner Begriffe
• Kontextgrenzen finden: Bedeutungswechsel von Begriffen, Änderungsrate, Zuständigkeit
• Ubiquitous Language: Glossar pflegen, Begriffe im Code verwenden, Sprachbrüche aufdecken
• Context Mapping: Partnership, Shared Kernel, Customer/Supplier und Conformist
• Das eigene Modell schützen: Anticorruption Layer, Open Host Service, Published Language

Taktisches Design

• Entities mit Identität und Lebenszyklus, Value Objects als unveränderliche Werte
• Aggregate und Aggregate Root: Invarianten schützen, eine Transaktion je Aggregat
• Aggregate klein halten: andere Aggregate nur über ihre ID referenzieren
• Domain Services für Fachlogik, die zu keinem einzelnen Objekt gehört
• Repositories: Aggregate laden und speichern, Persistenztechnik hinter einer Schnittstelle
• Factories für aufwendige Erzeugung, Application Services als dünne Steuerungsschicht
• Domain Events im Modell: fachlich bedeutsame Vorgänge in der Vergangenheitsform
• Umsetzung in Java: Value Objects als Records, Aggregate mit Fachmethoden statt Settern
• Hexagonale Architektur (Ports and Adapters) als Rahmen um das Domänenmodell
• Fachregeln als Unit-Tests ohne Datenbank und Framework prüfen
• Anämisches Domänenmodell erkennen und Verhalten aus Services zurück ins Modell holen

Event Storming – Komplexität sichtbar machen

• Ziel und Formate: Big Picture, Process Modelling und Software Design Event Storming
• Ablauf: freie Sammlung, Zeitleiste ordnen, Hotspots und Pivotal Events markieren
• Rollen: Moderation, Fachexpert:innen, Entwicklung – und wer nicht fehlen darf
• Raum, Papierbahn und Haftnotizen vor Ort; Remote-Variante auf einem digitalen Whiteboard
• Farbcode der Bausteine: Domain Event, Command, Policy, Aggregate, Read Model
• Akteure, externe Systeme und offene Fragen auf dem Board kennzeichnen
• Vom Board zur Architektur: Kontextgrenzen, Aggregate und Events ableiten
• Domain Storytelling mit Egon.io als Ergänzung für Abläufe aus Sicht der Beteiligten

Bounded Contexts und Microservices

• Wann Microservices sinnvoll sind – und wann ein Kontext als Modul im Monolithen besser bleibt
• Ein Kontext, ein Service? Zuschnitte von eins zu eins bis mehrere Services je Kontext
• Zusammenarbeit der Kontexte über Integration Events statt über eine geteilte Datenbank
• Published Language als versioniertes Schema, z. B. mit JSON Schema oder Avro
• Antimuster: Entity-Services, ein zentrales Kundenmodell für alle, lange Aufrufketten

Architekturformen im Vergleich

• Monolith, modularer Monolith mit einem Modul je Kontext und verteiltes System
• Modulgrenzen im Monolithen durchsetzen, z. B. mit Spring Modulith oder ArchUnit
• Orchestrierung über Prozessmanager oder Workflow-Engine, Choreografie über Events
• Reaktive, ereignisgetriebene Abläufe gegenüber deklarativ modellierten Prozessen mit BPMN
• CQRS: getrennte Schreib- und Lesemodelle innerhalb eines Bounded Context
• Event Sourcing: Zustand aus dem Ereignisstrom, Projektionen, Snapshots, Versionierung von Events
• Wann CQRS und Event Sourcing ihren Aufwand nicht rechtfertigen

DDD im Unternehmen einführen

• Modellierungshilfen der DDD Crew: Bounded Context Canvas und Aggregate Design Canvas
• Kontextkarten als Diagramm oder als Text mit der Context-Mapper-DSL pflegen
• Typische Hürden: kein Zugang zu Fachexpert:innen, Altdatenmodelle, Termindruck
• Einführung schrittweise: mit einer Kernsubdomäne beginnen und Ergebnisse zeigen
• Teamzuschnitt nach Kontexten: klare Zuständigkeit für Modell, Code und Daten
• Stolperfallen: Musterbegriffe ohne Fachgespräch, taktische Muster überall, Riesen-Aggregate
• Entscheidungen zum Kontextschnitt mit Begründung als ADR festhalten

Domain-Driven Design mit Coding-Agenten

• Glossar der Ubiquitous Language als Datei, aus der der Agent Klassen-, Methoden- und Event-Namen nimmt
• Fotos oder Exporte des Event-Storming-Boards vom Agenten in Events, Commands und Policies übertragen lassen
• Invarianten eines Aggregats zuerst als Tests festlegen, die Implementierung schreibt der Agent danach
• ApplicationModules.verify() von Spring Modulith nach jeder Agentenänderung als Grenzprüfung ausführen
• Agent sucht Sprachbrüche zwischen Glossar und Code sowie Setter, die Fachregeln umgehen

Praxisprojekt: Schadenregulierung einer Hausratversicherung

• Big-Picture-Event-Storming von der Schadenmeldung bis zur Auszahlung durchführen
• Subdomänen einordnen und Context Map mit Schadenaufnahme, Prüfung, Regulierung und Zahlung zeichnen
• Aggregat „Schadenfall“ mit Invarianten, Value Objects und Domain Events in Java umsetzen
• Anbindung der Zahlung über ein Integration Event und einen Anticorruption Layer zum Altsystem