DDD bietet eine zweifelsfreie Kommunikation fachlicher Aspekte aller teilnehmenden Personen.
Dazu beschreibt es Vorgehensweisen, die komplexe Software-Projekte transparenter für alle Beteiligten machen sollen.
https://www.meetup.com/de-DE/Scrumtisch-Weiden/events/257338847/
2. Überblick
● Was ist DDD?
● Allgemeines
● Vor -und Nachteile
● Beispiele
● Fazit
3. Was ist DDD?
DDD bietet eine zweifelsfreie Kommunikation fachlicher Aspekte aller teilnehmenden Personen.
● Eine einheitliche Sprache (Jeder weiß wovon gesprochen wird)
● Besitzt eigene Stilmittel und wohl definierte Vorgehensweisen
● Ständige agile und iterative Weiterentwicklung des Domänenmodells
● Bestimmung der Kernkomponente (Hauptnutzen)
● Zerlegung eines komplexen Projekts in kleinere abgetrennte Bausteine
5. Vor -und Nachteile
Pro
● Zweifelsfreie Kommunikation fachlicher Aspekte
● Bietet eine einheitliche Sprache für Fachlichkeiten
● Vision und Scope ist klar
● Funktionalität können getrennt von Teams
übernommen werden
● Time to market Zeit wird verkürzt
Contra
● Hoher Aufwand
● Schwierig wenn Fachabteilungen nicht mitarbeiten
/ nicht greifbar sind
6. DDD => Disassembled
Ziel: Softwaresystem in Module mit begrenzter Komplexität und klaren Schnittstellen zerlegen
1. Bestimmung + Koordination aller beteiligten Leute
2. Gemeinsame / einheitliche Vision schaffen
3. Softwaresystem / Produkt gemeinsam darstellen
4. Gemeinsame fachliche Sprache erarbeiten
5. Fachlicher Schnitt der Softwarebausteine ermitteln
6. Zerlegung eines Schnitts in kleinere Bausteine (Entitäten, Events, Wertobjekte)
7. Disziplin entwickeln agil und iterativ am Modell weiter zu arbeiten
8. Beziehungen finden 1. Beziehungen zwischen Geschäftsobjekten
finden
Client
Logic User
Todo Todo Liste
User Liste
9. Bounded Context
2. Festlegung der Bounded Contexts (fachlich
abgrenzbare Umfänge)
Bounded Context: Kerndomaine
Client
Logic
Bounded Context: TODO Service
Bounded Context: User Service
Todo Todo Liste
User User Liste
10. Context Mapping
3. Context Mapping zur Modellierung der
Schnittstellen
Implementierung einer Schnittstelle
via REST Custom Supplier Method Zwei Contexte (Teams) teilen sich einige Modellelemente. Achtung
Shared Code!!!
Ein vollständig unabhängiges Deployment der Microservices
ist bei diesem Muster nicht möglich.
11. Context Mapping
3. Context Mapping zur Modellierung der
Schnittstellen
Muster “Seperate Ways” dupliziert Geschäftsobjekte um getrennt an
den Contexten entwickeln zu können
15. Fazit
Nicht für jedes Projekt ist es sinnvoll, eine Migration zu
einer Microservices-Architektur durchzuführen. Deshalb
sollten alle Beteiligten im Vorfeld abklären, ob für eben
dieses Projekt die Vorteile wie etwa Skalierbarkeit,
unabhängiges Deployment oder schnelles Time-to-Market
durch agile Entwicklung überwiegen. Vor einer erfolgreichen
Umstellung steht immer der fachliche Schnitt auf Basis von
DDD. Dieser minimiert Abhängigkeiten zwischen den
Teams und Services
Module: fachliche Bestandteile der Domäne.
Entitäten: Objekte mit veränderlichen oder uneindeutigen Eigenschaften, die durch Ihre einzigartige Identität definiert sind (z. B. Personen).
Wertobjekte: Objekte, die durch ihre Eigenschaften eindeutig definiert sind und typischerweise unveränderlich bleiben.
Assoziationen: Beziehungen zwischen Objekten des Modells.
Aggregate: Einheit aus Objekten und deren Beziehungen.
Service-Objekte: fachlich relevante Funktionalitäten, die für mehrere Objekte der Domäne wichtig sind.
Fachliche Ereignisse: Spezielle Objekte registrieren fachlich relevante Ereignisse und machen sie für andere Domänenteile sichtbar (z. B. Ereignisse in einem Aggregat anderen Aggregaten der Domäne mitteilen).
Fabriken: Für komplexe Szenarien können verschiedene Erzeugungsmuster (meist factory oder builder patterns) herangezogen werden.
Repositories: saubere Trennung von Domänen- und Datenschicht für die Abstrahierung des Systems.
Im ersten Schritt der Domänenmodellierung modelliert das Team gemeinsam mit den Domänenexperten und der Entwicklung die beteiligten Geschäftsobjekte und deren Beziehungen. Hieraus entsteht ein erstes Domänenmodell, welches die geschäftskritischen Objekte sowie deren Abhängigkeiten zueinander darstellt.
Der zweite Schritt verfolgt das Ziel, die fachlich abgrenzbaren Umfänge („Bounded Contexts“) des Domänenmodells festzulegen. Die Kontexte sollten hierbei so gewählt sein, dass die Abhängigkeiten zwischen ihnen möglichst gering sind. Ein Negativ-Beispiel wäre der technisch-geprägte Schnitt in eine Datenhaltung (DB) und verschiedene Logik-Bausteine, der zu eng aneinander gekoppelten Services führt. Gibt es Änderungen, ziehen diese Anpassungen in diversen Services nach sich. Die Teams sind somit nicht in der Lage, Umfänge ohne längere Abstimmungen zu liefern. Use Cases beziehungsweise Szenarien können helfen, Abhängigkeiten zwischen Business-Objekten zu erkennen und eine gute Unterteilung in Kontexte vorzunehmen.
Ein weiteres Muster ist der „Shared Kernel“, bei dem zwei Kontexte (Teams) sich einige Modellelemente teilen (Abb. 6). Bei der Entwicklung der Services ist keine Schnittstelle notwendig. Stattdessen wird ein Teil des Codes sowie der Datenbank gemeinsam genutzt. Ein Vorteil davon ist, dass doppelter Code vermieden wird. Die Wahl dieses Musters sollte aber gut überlegt sein, denn es entsteht ein hoher Abstimmungsaufwand zwischen den Teams bezüglich Umsetzung und Pflege der gemeinsamen Objekte. Ein vollständig unabhängiges Deployment der Microservices ist bei diesem Muster nicht möglich.
Ein weiteres Muster ist der „Shared Kernel“, bei dem zwei Kontexte (Teams) sich einige Modellelemente teilen (Abb. 6). Bei der Entwicklung der Services ist keine Schnittstelle notwendig. Stattdessen wird ein Teil des Codes sowie der Datenbank gemeinsam genutzt. Ein Vorteil davon ist, dass doppelter Code vermieden wird. Die Wahl dieses Musters sollte aber gut überlegt sein, denn es entsteht ein hoher Abstimmungsaufwand zwischen den Teams bezüglich Umsetzung und Pflege der gemeinsamen Objekte. Ein vollständig unabhängiges Deployment der Microservices ist bei diesem Muster nicht möglich.
Es gibt noch viel zu tun um DDD zu verbessern. (Nach über 15 Jahren gibt es noch offene Punkte zur Verbesserung)
