Downloaden Sie, um offline zu lesen
DDD - Domain Driven Design
- 1. DDD - DomainDriven Design Tobias Frischholz
- 2. Überblick ● Was istDDD? ● Allgemeines ● Vor -und Nachteile ● Beispiele ● Fazit
- 3. Was ist DDD? DDDbietet 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
- 4. Allgemeines ● Eine gutedefinierte Vorgehensweise erleichtern komplexe Projekte Elemente des Domain-driven Design ● Module ● Entitäten ● Wertobjekte ● Assoziationen ● Aggregate ● Service-Objekte ● Fachliche Ereignisse ● Fabriken ● Repositories
- 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
- 7. Beispiel Mit Domain-DrivenDesign zu einem guten fachlichen Schnitt
- 8. Beziehungen finden 1.Beziehungen zwischen Geschäftsobjekten finden Client Logic User Todo Todo Liste User Liste
- 9. Bounded Context 2. Festlegungder 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. ContextMapping 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. ContextMapping zur Modellierung der Schnittstellen Muster “Seperate Ways” dupliziert Geschäftsobjekte um getrennt an den Contexten entwickeln zu können
- 12.
- 13.
- 14. "DDD Isn’t Done" – Eric Evans (Author Domain Driven Design) -> 2003
- 15. Fazit Nicht für jedesProjekt 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
- 16.
Hinweis der Redaktion
- #5 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.
- #9 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.
- #10 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.
- #11 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.
- #12 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.
- #15 Es gibt noch viel zu tun um DDD zu verbessern. (Nach über 15 Jahren gibt es noch offene Punkte zur Verbesserung)