Der nachfolgende Text wurden mit KI erstellt und kann Fehler enthalten. Fehler gefunden? Bei GitHub editieren
Domain-Driven Design (DDD) bietet eine Vielzahl wertvoller Werkzeuge für die Softwareentwicklung. Diese Episode zeigt anhand eines E-Commerce-Beispiels, wie die verschiedenen DDD-Konzepte ineinandergreifen und in der Praxis angewendet werden können.
Event Storming als Startpunkt
Event Storming ist eine effektive Methode, um Domain-Experten und Entwickler zusammenzubringen. Dabei werden wichtige Geschäftsereignisse (Domain Events) auf orangefarbene Haftnotizen geschrieben und chronologisch angeordnet. Ein Event wird dabei in der Vergangenheitsform formuliert, zum Beispiel “Bestellung akzeptiert”.
Der Prozess beginnt mit einer “Chaotic Exploration”-Phase, in der möglichst viele Events gesammelt werden. Anschließend werden diese Events in eine zeitliche Abfolge gebracht (“Timeline Enforcement”). Parallel laufende Prozesse können in separaten Swimlanes organisiert werden, etwa Rechnungsstellung und Auslieferung.
Besonders wichtig sind sogenannte “Pivotal Events” - Ereignisse, nach denen sich der Zustand des Systems fundamental ändert. Im E-Commerce-Beispiel wäre “Bestellung akzeptiert” ein solches Event, da danach keine einfachen Änderungen am Warenkorb mehr möglich sind.
Bounded Contexts identifizieren
Aus dem Event Storming lassen sich Bounded Contexts ableiten - in sich geschlossene fachliche Teilbereiche mit eigener Sprache und eigenem Modell. Im Beispiel ergeben sich drei Contexts:
- Bestellprozess
- Rechnungsstellung
- Lieferung
Jeder Bounded Context sollte idealerweise von einem Team verantwortet werden. Die Grenzen zwischen den Contexts orientieren sich an den Pivotal Events und Swimlanes aus dem Event Storming.
Core Domain Analysis
Ein zentraler Aspekt von DDD ist die Identifikation der Core Domain - des Bereichs, der den größten strategischen Wert für das Unternehmen hat. Entgegen der intuitiven Annahme muss dies nicht der Bestellprozess sein. Wenn sich das Unternehmen durch besonders schnelle und zuverlässige Lieferung differenziert, wäre der Lieferprozess die Core Domain.
Die übrigen Bereiche sind entweder:
- Generic Subdomains (standardisierte Funktionen, die zugekauft werden können)
- Supporting Subdomains (selbst entwickelte Hilfsfunktionen)
Strategisches Design der Zusammenarbeit
Die Core Domain muss von den anderen Bereichen optimal unterstützt werden. DDD bietet dafür verschiedene Collaboration Patterns:
- Customer/Supplier: Der “Supplier” (z.B. Bestellprozess) unterstützt den “Customer” (z.B. Lieferprozess) durch Bereitstellung benötigter Funktionen
- Conformist: Ein Bereich muss sich an die Vorgaben eines anderen anpassen.
Alternativ bietet der Team Topologies Ansatz ein intuitiveres Modell für die Zusammenarbeit:
- Stream-aligned Teams verantworten den vollständigen Änderungsprozess von Funktionalitäten
- Platform Teams stellen Services (z.B. einen Kubernetes-Cluster) als interne Produkte bereit
- Enabling Teams unterstützen beim Aufbau von Fähigkeiten
- Complicated Subsystem Teams kümmern sich um komplexe Algorithmen
Die Zusammenarbeit erfolgt über definierte Interaktionsmodi wie “Collaboration” oder “X-as-a-Service”.
Fazit
Domain-Driven Design bietet einen umfassenden Werkzeugkasten für die fachlich getriebene Softwareentwicklung. Der Erfolg hängt dabei nicht nur von der technischen Umsetzung ab, sondern auch von der richtigen organisatorischen Einbettung. Die vorgestellten Methoden helfen dabei, von der ersten Analyse bis zur konkreten Team-Struktur die richtigen Entscheidungen zu treffen.
Die Herausforderung liegt oft weniger in den einzelnen Konzepten als in deren geschickter Kombination und der Berücksichtigung der organisatorischen Realität. Ein pragmatischer Ansatz, der die Methoden gezielt dort einsetzt wo sie den größten Nutzen bringen, verspricht den meisten Erfolg.