SlideShare ist ein Scribd-Unternehmen logo
1 von 16
DDD - Domain Driven Design
Tobias Frischholz
Überblick
● Was ist DDD?
● Allgemeines
● Vor -und Nachteile
● Beispiele
● Fazit
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
Allgemeines
● Eine gute definierte Vorgehensweise
erleichtern komplexe Projekte
Elemente des Domain-driven Design
● Module
● Entitäten
● Wertobjekte
● Assoziationen
● Aggregate
● Service-Objekte
● Fachliche Ereignisse
● Fabriken
● Repositories
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
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
Beispiel Mit Domain-Driven Design zu
einem guten fachlichen
Schnitt
Beziehungen finden 1. Beziehungen zwischen Geschäftsobjekten
finden
Client
Logic User
Todo Todo Liste
User Liste
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
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.
Context Mapping
3. Context Mapping zur Modellierung der
Schnittstellen
Muster “Seperate Ways” dupliziert Geschäftsobjekte um getrennt an
den Contexten entwickeln zu können
Zur verteilten Datenbank
Zur verteilten Oberfläche
"DDD Isn’t Done "
– Eric Evans (Author Domain Driven Design) -> 2003
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
Vielen Dank!
Tobias Frischholz

Weitere ähnliche Inhalte

Ähnlich wie DDD - Domain Driven Design

DACHNUG50 Erfolgreiche Digitalisierung Notes Anwendungen mit Low Code L”sung ...
DACHNUG50 Erfolgreiche Digitalisierung Notes Anwendungen mit Low Code L”sung ...DACHNUG50 Erfolgreiche Digitalisierung Notes Anwendungen mit Low Code L”sung ...
DACHNUG50 Erfolgreiche Digitalisierung Notes Anwendungen mit Low Code L”sung ...DNUG e.V.
 
Top 10 Internet Trends 2001
Top 10 Internet Trends 2001Top 10 Internet Trends 2001
Top 10 Internet Trends 2001Jürg Stuker
 
PLM Open Hours - Dokumentation von Projekten mit Implementierungsanteil
PLM Open Hours - Dokumentation von Projekten mit ImplementierungsanteilPLM Open Hours - Dokumentation von Projekten mit Implementierungsanteil
PLM Open Hours - Dokumentation von Projekten mit ImplementierungsanteilIntelliact AG
 
Übersetzungsproduktivität: Der nächste Schritt
Übersetzungsproduktivität: Der nächste SchrittÜbersetzungsproduktivität: Der nächste Schritt
Übersetzungsproduktivität: Der nächste SchrittSDL Language Technologies
 
Software Architecture Design Patterns der COMLINE Cloud Service Platform - CSP
Software Architecture Design Patterns der COMLINE Cloud Service Platform - CSPSoftware Architecture Design Patterns der COMLINE Cloud Service Platform - CSP
Software Architecture Design Patterns der COMLINE Cloud Service Platform - CSPChristian Guenther
 
Microsoft Project meets PMBOK - den internationalen Projektmanagement-Standard
Microsoft Project meets PMBOK - den internationalen Projektmanagement-StandardMicrosoft Project meets PMBOK - den internationalen Projektmanagement-Standard
Microsoft Project meets PMBOK - den internationalen Projektmanagement-StandardDigicomp Academy AG
 
Microservices - Was EAs zu Microservices wissen sollten
Microservices - Was EAs zu Microservices wissen solltenMicroservices - Was EAs zu Microservices wissen sollten
Microservices - Was EAs zu Microservices wissen solltenJan Thielscher
 
Erp in der zukunft: über die funktionen hinaus
Erp in der zukunft: über die funktionen hinausErp in der zukunft: über die funktionen hinaus
Erp in der zukunft: über die funktionen hinausDedagroup
 
Teamarbeit 2.0 (PTF 2008)
Teamarbeit 2.0 (PTF 2008) Teamarbeit 2.0 (PTF 2008)
Teamarbeit 2.0 (PTF 2008) Thomas Koch
 
Implementierung der Knowledge Engineering Workbench in myCBR
Implementierung der Knowledge Engineering Workbench in myCBRImplementierung der Knowledge Engineering Workbench in myCBR
Implementierung der Knowledge Engineering Workbench in myCBRAlexander Hundt
 
Onno Reiners: E-Learning einfach selbst erstellen
Onno Reiners: E-Learning einfach selbst erstellenOnno Reiners: E-Learning einfach selbst erstellen
Onno Reiners: E-Learning einfach selbst erstellenlernet
 
2011 07-13 collaboration solutions day - cedros
2011 07-13 collaboration solutions day - cedros2011 07-13 collaboration solutions day - cedros
2011 07-13 collaboration solutions day - cedrosPhilipp_Koenigs
 
IA Konferenz 2009
IA Konferenz 2009IA Konferenz 2009
IA Konferenz 2009Jutta Korn
 
Requirement Engineering & PDD
Requirement Engineering & PDDRequirement Engineering & PDD
Requirement Engineering & PDDCristina Vidu
 
Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...
Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...
Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...QAware GmbH
 

Ähnlich wie DDD - Domain Driven Design (20)

Domain-Driven Design
Domain-Driven DesignDomain-Driven Design
Domain-Driven Design
 
Domain Driven Design - Stabile Basis für langlebige Software
Domain Driven Design - Stabile Basis für langlebige SoftwareDomain Driven Design - Stabile Basis für langlebige Software
Domain Driven Design - Stabile Basis für langlebige Software
 
OSLC in Aktion
OSLC in AktionOSLC in Aktion
OSLC in Aktion
 
DACHNUG50 Erfolgreiche Digitalisierung Notes Anwendungen mit Low Code L”sung ...
DACHNUG50 Erfolgreiche Digitalisierung Notes Anwendungen mit Low Code L”sung ...DACHNUG50 Erfolgreiche Digitalisierung Notes Anwendungen mit Low Code L”sung ...
DACHNUG50 Erfolgreiche Digitalisierung Notes Anwendungen mit Low Code L”sung ...
 
Top 10 Internet Trends 2001
Top 10 Internet Trends 2001Top 10 Internet Trends 2001
Top 10 Internet Trends 2001
 
TDD für Testmuffel
TDD für TestmuffelTDD für Testmuffel
TDD für Testmuffel
 
PLM Open Hours - Dokumentation von Projekten mit Implementierungsanteil
PLM Open Hours - Dokumentation von Projekten mit ImplementierungsanteilPLM Open Hours - Dokumentation von Projekten mit Implementierungsanteil
PLM Open Hours - Dokumentation von Projekten mit Implementierungsanteil
 
Domain Driven Design - Stabile Basis für langlebige Software
Domain Driven Design - Stabile Basis für langlebige SoftwareDomain Driven Design - Stabile Basis für langlebige Software
Domain Driven Design - Stabile Basis für langlebige Software
 
Übersetzungsproduktivität: Der nächste Schritt
Übersetzungsproduktivität: Der nächste SchrittÜbersetzungsproduktivität: Der nächste Schritt
Übersetzungsproduktivität: Der nächste Schritt
 
Software Architecture Design Patterns der COMLINE Cloud Service Platform - CSP
Software Architecture Design Patterns der COMLINE Cloud Service Platform - CSPSoftware Architecture Design Patterns der COMLINE Cloud Service Platform - CSP
Software Architecture Design Patterns der COMLINE Cloud Service Platform - CSP
 
Microsoft Project meets PMBOK - den internationalen Projektmanagement-Standard
Microsoft Project meets PMBOK - den internationalen Projektmanagement-StandardMicrosoft Project meets PMBOK - den internationalen Projektmanagement-Standard
Microsoft Project meets PMBOK - den internationalen Projektmanagement-Standard
 
Microservices - Was EAs zu Microservices wissen sollten
Microservices - Was EAs zu Microservices wissen solltenMicroservices - Was EAs zu Microservices wissen sollten
Microservices - Was EAs zu Microservices wissen sollten
 
Erp in der zukunft: über die funktionen hinaus
Erp in der zukunft: über die funktionen hinausErp in der zukunft: über die funktionen hinaus
Erp in der zukunft: über die funktionen hinaus
 
Teamarbeit 2.0 (PTF 2008)
Teamarbeit 2.0 (PTF 2008) Teamarbeit 2.0 (PTF 2008)
Teamarbeit 2.0 (PTF 2008)
 
Implementierung der Knowledge Engineering Workbench in myCBR
Implementierung der Knowledge Engineering Workbench in myCBRImplementierung der Knowledge Engineering Workbench in myCBR
Implementierung der Knowledge Engineering Workbench in myCBR
 
Onno Reiners: E-Learning einfach selbst erstellen
Onno Reiners: E-Learning einfach selbst erstellenOnno Reiners: E-Learning einfach selbst erstellen
Onno Reiners: E-Learning einfach selbst erstellen
 
2011 07-13 collaboration solutions day - cedros
2011 07-13 collaboration solutions day - cedros2011 07-13 collaboration solutions day - cedros
2011 07-13 collaboration solutions day - cedros
 
IA Konferenz 2009
IA Konferenz 2009IA Konferenz 2009
IA Konferenz 2009
 
Requirement Engineering & PDD
Requirement Engineering & PDDRequirement Engineering & PDD
Requirement Engineering & PDD
 
Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...
Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...
Make Agile Great - PM-Erfahrungen aus zwei virtuellen internationalen SAFe-Pr...
 

DDD - Domain Driven Design

  • 1. DDD - Domain Driven Design Tobias Frischholz
  • 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
  • 4. Allgemeines ● Eine gute definierte 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-Driven Design 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. 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
  • 14. "DDD Isn’t Done " – Eric Evans (Author Domain Driven Design) -> 2003
  • 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

Hinweis der Redaktion

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. Es gibt noch viel zu tun um DDD zu verbessern. (Nach über 15 Jahren gibt es noch offene Punkte zur Verbesserung)