SlideShare une entreprise Scribd logo
1  sur  24
Télécharger pour lire hors ligne
Domain-Driven Design
Was ist DDD?

Domain Driven Design ist ein von Eric Evans geprägter Begriff für
eine Anwendungsdomänen-getriebene Herangehensweise an das
Design komplexer objektorientierter Software.
Geistige Väter des DDD

•
•
•

Jimmy Nilsson
Eric Evans
Martin Fowler
Was ist eine Domäne?

• im Softwarekontext eine Problemdomäne
• ein abgrenzbares Problemfeld oder einen
bestimmten Einsatzbereich für Software

• im Folgenden steht Fachdomäne für die

Probleme des Kunden und
Anwendungsdomäne für die Represäntation
der Fachdomäne auf Seite des
Dienstleisters
Was ist ein Modell?

• ein Model ist eine auf bestimmte Zwecke

ausgerichtete vereinfachende Beschreibung
der Wirklichkeit

• zum Beispiel eine Bauzeichnung
Was bietet mir DDD?
•

es vereinheitlicht das Verständnis der Fachdomäne
zwischen allen Projektbeteiligten

•

es hält die Differenz zwischen der Fachdomäne
und der Anwendungsdomäne möglichst klein

•

es verhindert ein anemisches Anwendungsmodell
(ein Modell ohne Fachlogik)

•

es teilt die Komplexität der Fachdomäne in
verständliche Teile
Was bietet mir DDD?
•

es ermöglicht das iterative Analysieren der
Fachdomäne

•

es erlaubt die iterative Entwicklung des
Anwendungsmodells

•

es trennt die Software in gut wartbare Teile mit
wenig Seiteneffekten

•

es erleichtert neuen Projektteilnehmern den
Einstieg
Und wie geht das?

• Kunde (Domänenexperte) und

Dienstleister (PM & Entwickler)
kartografieren gemeinsam die Fachdomäne

• Bestandteile werden erkannt und benannt
• ein kontinuierlicher Prozess (iterativ/agil)
• Ergebnis ist das Anwendungsmodell, das
die Anwendungsdomäne repräsentiert
Und wie geht das?

• die Namen der Bestandteile werden Teil

der „ubiquitous language“
(allgegenwärtige und gemeinsame Sprache)

• diese Sprache wird von allen

Projektbeteiligten gesprochen und im
Modell verwendet
Wo platziere ich das Modell
in meiner Anwedung?
User Interface
Anwendung
Modell
Infrastruktur
Bausteine des DDD

• Entities
• Value Objects
• Aggregates
• Relations
• Repositories

• Factories
• Services
• [Modules]
• [Domain Events]
Domain Objects

• repräsentieren Objekte der Fachdomäne
• beinhalten die Fachlogik
• werden durch…
• eine einzigartige Identität
• oder ihre Eigenenschaften
• …in einer Menge von Objekten gleichen
Typs identifiziert
Domain Objects
Value Objects

• identifizierbar durch ihre Eigenschaften
• z.B. Adresse eines Geschäfts
Entities

• identifizierbar durch ihre Identität
• z.B. das Geschäft selbst
Relations

• sind die Beziehungen zwischen zwei oder
mehreren Domain Objects
Aggregate

• sind Zusammenfassungen von Entities,Value
Objects und deren Relations untereinander

• sind selbst ein Entity
• der Zugriff auf die beinhalteten Objekte

erfolgt ausschließlich über das Aggregate
Domain Services

• Prozesse, die nicht direkt einem Domain
Object zuzuordnen sind

• steuert Interaktion zwischen Verschiedenen
Domain Objects

• z.B. Überweisungen zwischen zwei
Bankkonten zweier Kunden
Repositories

• speichern und finden Entities
• abstrahieren die Persistenz (das Speichern
und Wiederherstellen von Objekten)

• sind die Schnittstelle zur Infrastruktur
Factories

• erzeugen Domain Objects wenn die

Erzeugung für das Domain Object selbst zu
komplex ist

• werden benötigt wenn z.B. Relations bei

der Erzeugung aufgebaut werden müssen
Aber wie halte ich mein Modell
„sauber“?

• besonders wenn mehrere Entwickler in der
Anwendungsdomäne arbeiten ist das
schwierig

• DDD bietet dafür einige Verfahrensweisen
• Bounded Context
• Context Map
• Core Domain
• Shared Kernel
Bounded Context

• beschreibt die Grenzen des Kontexts einer
Anwendungsdomäne hinsichtlich

• Verwendungszweck
• Teamzuordnung
• Implementierungsdetails

• Verantwortlichkeiten werden klar
abgebildet
Context Map

• beschreibt in Vogelperspektive die Grenzen
und Schnittstellen der Bounded Contexts
zueinander

• verhindert das Überschreiten von Grenzen
zwischen Bounded Contexts

• beschreibt die Kommunikation zwischen
Bounded Contexts über deren
Schnittstellen
Core Domain

• ist der wertvollste Teil des Fachmodells
• muss besonders „sauber“ bleiben
• andere Teile des Modells reichern diesen
Teil in seiner Tätigkeit nur an

• sollte von den besten Entwicklern im Team
betreut werden
Shared Kernel

• ist die gemeinsame Schnittmenge zwischen
Bounded Contexts

• wird in enger Abstimmung von den Teams
der Bounded Contexts gemeinsam
weiterentwickelt
Fragen?

Contenu connexe

Similaire à Domain-Driven Design

DDD - Domain Driven Design
DDD - Domain Driven DesignDDD - Domain Driven Design
DDD - Domain Driven DesignTobiasFrischholz
 
Mit Domain-driven Design (DDD) nützliche und flexible Software bauen
Mit Domain-driven Design (DDD) nützliche und flexible Software bauenMit Domain-driven Design (DDD) nützliche und flexible Software bauen
Mit Domain-driven Design (DDD) nützliche und flexible Software bauenDigicomp Academy AG
 
2007 - Basta!: Nach soa kommt soc
2007 - Basta!: Nach soa kommt soc2007 - Basta!: Nach soa kommt soc
2007 - Basta!: Nach soa kommt socDaniel Fisher
 
Softwerkskammer Chemnitz Special Pecha Kucha Night
Softwerkskammer Chemnitz Special Pecha Kucha NightSoftwerkskammer Chemnitz Special Pecha Kucha Night
Softwerkskammer Chemnitz Special Pecha Kucha NightChristinaLerch1
 
comundus Kundenportal mit Liferay
comundus Kundenportal mit Liferaycomundus Kundenportal mit Liferay
comundus Kundenportal mit LiferayStefan Hilpp
 
AdminCamp2017 - ApplicationInsights
AdminCamp2017 - ApplicationInsightsAdminCamp2017 - ApplicationInsights
AdminCamp2017 - ApplicationInsightsChristoph Adler
 
Ü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
 
DNUG 2017 - ApplicationInsights
DNUG 2017 - ApplicationInsightsDNUG 2017 - ApplicationInsights
DNUG 2017 - ApplicationInsightsChristoph Adler
 
Robuste Design Systems mit Storybook und Angular: vom Konzept zur lebendigen ...
Robuste Design Systems mit Storybook und Angular: vom Konzept zur lebendigen ...Robuste Design Systems mit Storybook und Angular: vom Konzept zur lebendigen ...
Robuste Design Systems mit Storybook und Angular: vom Konzept zur lebendigen ...Andreas Wissel
 
Schau, Mutti, keine Programmierzeile
Schau, Mutti, keine ProgrammierzeileSchau, Mutti, keine Programmierzeile
Schau, Mutti, keine Programmierzeilerokr
 
DNUG - ApplicationInsights: So analysieren, optimieren und modernisieren Sie ...
DNUG - ApplicationInsights: So analysieren, optimieren und modernisieren Sie ...DNUG - ApplicationInsights: So analysieren, optimieren und modernisieren Sie ...
DNUG - ApplicationInsights: So analysieren, optimieren und modernisieren Sie ...panagenda
 
Creasoft - Windows Azure
Creasoft - Windows AzureCreasoft - Windows Azure
Creasoft - Windows AzureCreasoft AG
 
Agile Softwareentwicklung mit Rails
Agile Softwareentwicklung mit RailsAgile Softwareentwicklung mit Rails
Agile Softwareentwicklung mit RailsHussein Morsy
 
ULC Connect-Nachlese, 06.03.2014 Dresden
ULC Connect-Nachlese, 06.03.2014 DresdenULC Connect-Nachlese, 06.03.2014 Dresden
ULC Connect-Nachlese, 06.03.2014 DresdenJRibbeck
 
Plattform im wandel nosa 04-04-2017
Plattform im wandel   nosa 04-04-2017Plattform im wandel   nosa 04-04-2017
Plattform im wandel nosa 04-04-2017JRibbeck
 
Prozessmanagement SaaS, Workflow Management SaaS, Prozesse Software as a Service
Prozessmanagement SaaS, Workflow Management SaaS, Prozesse Software as a ServiceProzessmanagement SaaS, Workflow Management SaaS, Prozesse Software as a Service
Prozessmanagement SaaS, Workflow Management SaaS, Prozesse Software as a ServiceGBS PAVONE Groupware GmbH
 
Die Microsoft Online Services - Was kann die Cloud für mein Unternehmen tun
Die Microsoft Online Services - Was kann die Cloud für mein Unternehmen tun Die Microsoft Online Services - Was kann die Cloud für mein Unternehmen tun
Die Microsoft Online Services - Was kann die Cloud für mein Unternehmen tun Christian Kiesewetter
 
Groupware Linuxtag 2008 Cb
Groupware Linuxtag 2008 CbGroupware Linuxtag 2008 Cb
Groupware Linuxtag 2008 Cbbofh42
 
100% ECM für SharePoint mit ecspand
100% ECM für SharePoint mit ecspand100% ECM für SharePoint mit ecspand
100% ECM für SharePoint mit ecspandChristian Kiesewetter
 

Similaire à Domain-Driven Design (20)

DDD - Domain Driven Design
DDD - Domain Driven DesignDDD - Domain Driven Design
DDD - Domain Driven Design
 
Mit Domain-driven Design (DDD) nützliche und flexible Software bauen
Mit Domain-driven Design (DDD) nützliche und flexible Software bauenMit Domain-driven Design (DDD) nützliche und flexible Software bauen
Mit Domain-driven Design (DDD) nützliche und flexible Software bauen
 
2007 - Basta!: Nach soa kommt soc
2007 - Basta!: Nach soa kommt soc2007 - Basta!: Nach soa kommt soc
2007 - Basta!: Nach soa kommt soc
 
Softwerkskammer Chemnitz Special Pecha Kucha Night
Softwerkskammer Chemnitz Special Pecha Kucha NightSoftwerkskammer Chemnitz Special Pecha Kucha Night
Softwerkskammer Chemnitz Special Pecha Kucha Night
 
comundus Kundenportal mit Liferay
comundus Kundenportal mit Liferaycomundus Kundenportal mit Liferay
comundus Kundenportal mit Liferay
 
AdminCamp2017 - ApplicationInsights
AdminCamp2017 - ApplicationInsightsAdminCamp2017 - ApplicationInsights
AdminCamp2017 - ApplicationInsights
 
Übersetzungsproduktivität: Der nächste Schritt
Übersetzungsproduktivität: Der nächste SchrittÜbersetzungsproduktivität: Der nächste Schritt
Übersetzungsproduktivität: Der nächste Schritt
 
DNUG 2017 - ApplicationInsights
DNUG 2017 - ApplicationInsightsDNUG 2017 - ApplicationInsights
DNUG 2017 - ApplicationInsights
 
Robuste Design Systems mit Storybook und Angular: vom Konzept zur lebendigen ...
Robuste Design Systems mit Storybook und Angular: vom Konzept zur lebendigen ...Robuste Design Systems mit Storybook und Angular: vom Konzept zur lebendigen ...
Robuste Design Systems mit Storybook und Angular: vom Konzept zur lebendigen ...
 
Schau, Mutti, keine Programmierzeile
Schau, Mutti, keine ProgrammierzeileSchau, Mutti, keine Programmierzeile
Schau, Mutti, keine Programmierzeile
 
DNUG - ApplicationInsights: So analysieren, optimieren und modernisieren Sie ...
DNUG - ApplicationInsights: So analysieren, optimieren und modernisieren Sie ...DNUG - ApplicationInsights: So analysieren, optimieren und modernisieren Sie ...
DNUG - ApplicationInsights: So analysieren, optimieren und modernisieren Sie ...
 
Creasoft - Windows Azure
Creasoft - Windows AzureCreasoft - Windows Azure
Creasoft - Windows Azure
 
Alfresco Workdesk (German)
Alfresco Workdesk (German)Alfresco Workdesk (German)
Alfresco Workdesk (German)
 
Agile Softwareentwicklung mit Rails
Agile Softwareentwicklung mit RailsAgile Softwareentwicklung mit Rails
Agile Softwareentwicklung mit Rails
 
ULC Connect-Nachlese, 06.03.2014 Dresden
ULC Connect-Nachlese, 06.03.2014 DresdenULC Connect-Nachlese, 06.03.2014 Dresden
ULC Connect-Nachlese, 06.03.2014 Dresden
 
Plattform im wandel nosa 04-04-2017
Plattform im wandel   nosa 04-04-2017Plattform im wandel   nosa 04-04-2017
Plattform im wandel nosa 04-04-2017
 
Prozessmanagement SaaS, Workflow Management SaaS, Prozesse Software as a Service
Prozessmanagement SaaS, Workflow Management SaaS, Prozesse Software as a ServiceProzessmanagement SaaS, Workflow Management SaaS, Prozesse Software as a Service
Prozessmanagement SaaS, Workflow Management SaaS, Prozesse Software as a Service
 
Die Microsoft Online Services - Was kann die Cloud für mein Unternehmen tun
Die Microsoft Online Services - Was kann die Cloud für mein Unternehmen tun Die Microsoft Online Services - Was kann die Cloud für mein Unternehmen tun
Die Microsoft Online Services - Was kann die Cloud für mein Unternehmen tun
 
Groupware Linuxtag 2008 Cb
Groupware Linuxtag 2008 CbGroupware Linuxtag 2008 Cb
Groupware Linuxtag 2008 Cb
 
100% ECM für SharePoint mit ecspand
100% ECM für SharePoint mit ecspand100% ECM für SharePoint mit ecspand
100% ECM für SharePoint mit ecspand
 

Domain-Driven Design

  • 2. Was ist DDD? Domain Driven Design ist ein von Eric Evans geprägter Begriff für eine Anwendungsdomänen-getriebene Herangehensweise an das Design komplexer objektorientierter Software.
  • 3. Geistige Väter des DDD • • • Jimmy Nilsson Eric Evans Martin Fowler
  • 4. Was ist eine Domäne? • im Softwarekontext eine Problemdomäne • ein abgrenzbares Problemfeld oder einen bestimmten Einsatzbereich für Software • im Folgenden steht Fachdomäne für die Probleme des Kunden und Anwendungsdomäne für die Represäntation der Fachdomäne auf Seite des Dienstleisters
  • 5. Was ist ein Modell? • ein Model ist eine auf bestimmte Zwecke ausgerichtete vereinfachende Beschreibung der Wirklichkeit • zum Beispiel eine Bauzeichnung
  • 6. Was bietet mir DDD? • es vereinheitlicht das Verständnis der Fachdomäne zwischen allen Projektbeteiligten • es hält die Differenz zwischen der Fachdomäne und der Anwendungsdomäne möglichst klein • es verhindert ein anemisches Anwendungsmodell (ein Modell ohne Fachlogik) • es teilt die Komplexität der Fachdomäne in verständliche Teile
  • 7. Was bietet mir DDD? • es ermöglicht das iterative Analysieren der Fachdomäne • es erlaubt die iterative Entwicklung des Anwendungsmodells • es trennt die Software in gut wartbare Teile mit wenig Seiteneffekten • es erleichtert neuen Projektteilnehmern den Einstieg
  • 8. Und wie geht das? • Kunde (Domänenexperte) und Dienstleister (PM & Entwickler) kartografieren gemeinsam die Fachdomäne • Bestandteile werden erkannt und benannt • ein kontinuierlicher Prozess (iterativ/agil) • Ergebnis ist das Anwendungsmodell, das die Anwendungsdomäne repräsentiert
  • 9. Und wie geht das? • die Namen der Bestandteile werden Teil der „ubiquitous language“ (allgegenwärtige und gemeinsame Sprache) • diese Sprache wird von allen Projektbeteiligten gesprochen und im Modell verwendet
  • 10. Wo platziere ich das Modell in meiner Anwedung? User Interface Anwendung Modell Infrastruktur
  • 11. Bausteine des DDD • Entities • Value Objects • Aggregates • Relations • Repositories • Factories • Services • [Modules] • [Domain Events]
  • 12. Domain Objects • repräsentieren Objekte der Fachdomäne • beinhalten die Fachlogik • werden durch… • eine einzigartige Identität • oder ihre Eigenenschaften • …in einer Menge von Objekten gleichen Typs identifiziert
  • 13. Domain Objects Value Objects • identifizierbar durch ihre Eigenschaften • z.B. Adresse eines Geschäfts Entities • identifizierbar durch ihre Identität • z.B. das Geschäft selbst
  • 14. Relations • sind die Beziehungen zwischen zwei oder mehreren Domain Objects
  • 15. Aggregate • sind Zusammenfassungen von Entities,Value Objects und deren Relations untereinander • sind selbst ein Entity • der Zugriff auf die beinhalteten Objekte erfolgt ausschließlich über das Aggregate
  • 16. Domain Services • Prozesse, die nicht direkt einem Domain Object zuzuordnen sind • steuert Interaktion zwischen Verschiedenen Domain Objects • z.B. Überweisungen zwischen zwei Bankkonten zweier Kunden
  • 17. Repositories • speichern und finden Entities • abstrahieren die Persistenz (das Speichern und Wiederherstellen von Objekten) • sind die Schnittstelle zur Infrastruktur
  • 18. Factories • erzeugen Domain Objects wenn die Erzeugung für das Domain Object selbst zu komplex ist • werden benötigt wenn z.B. Relations bei der Erzeugung aufgebaut werden müssen
  • 19. Aber wie halte ich mein Modell „sauber“? • besonders wenn mehrere Entwickler in der Anwendungsdomäne arbeiten ist das schwierig • DDD bietet dafür einige Verfahrensweisen • Bounded Context • Context Map • Core Domain • Shared Kernel
  • 20. Bounded Context • beschreibt die Grenzen des Kontexts einer Anwendungsdomäne hinsichtlich • Verwendungszweck • Teamzuordnung • Implementierungsdetails • Verantwortlichkeiten werden klar abgebildet
  • 21. Context Map • beschreibt in Vogelperspektive die Grenzen und Schnittstellen der Bounded Contexts zueinander • verhindert das Überschreiten von Grenzen zwischen Bounded Contexts • beschreibt die Kommunikation zwischen Bounded Contexts über deren Schnittstellen
  • 22. Core Domain • ist der wertvollste Teil des Fachmodells • muss besonders „sauber“ bleiben • andere Teile des Modells reichern diesen Teil in seiner Tätigkeit nur an • sollte von den besten Entwicklern im Team betreut werden
  • 23. Shared Kernel • ist die gemeinsame Schnittmenge zwischen Bounded Contexts • wird in enger Abstimmung von den Teams der Bounded Contexts gemeinsam weiterentwickelt