1. Domain Driven Design
1

2. Gründe für Domain Driven
Design?
Datum: 06.12.2011 Domain Driven Design Markus Goldbeck
2
2

3. Typische Projekte?
Driven
Datum: 06.12.2011 Domain Driven Design Markus Goldbeck
3
3

4. Typische Projekte?
Datum: 06.12.2011 Domain Driven Design Markus Goldbeck
4
4

5. Grundproblem
Vorstellung Kunde
Unterschiedliches
Verständnis der
domänenspezifischen
Konzepte
Vorstellung
Datum: 06.12.2011 Domain Driven Design Markus Goldbeck
5
5

6. Was ist Domain Driven
Design?
Datum: 06.12.2011 Domain Driven Design Markus Goldbeck
6
6

7. Definition Domain Driven Design
Domain Driven Design ist ein von Eric Evans
geprägter Begriff für eine Anwendungsdomänen-
getriebene Herangehensweise an das Design
komplexer objektorientierter Software.
Datum: 06.12.2011 Domain Driven Design Markus Goldbeck
7
7

8. Definition Domain Driven Design
Domain Driven Design ist nicht nur eine Technik
oder Methode, sondern eine Denkweise, ein Set an
Handlungsanweisungen, letztlich eine
Philosophie.
Datum: 06.12.2011 Domain Driven Design Markus Goldbeck
8
8

9. Wer hat‘s erfunden?
JIMMY NILSSON ERIC EVANS MARTIN FOWLER
Datum: 06.12.2011 Domain Driven Design Markus Goldbeck
9
9

10. Grundsatz Domain Driven Design
Domain Driven Design basiert auf zwei Annahmen:
•Der Schwerpunkt des Softwaredesigns liegt auf
der Fachlichkeit und der Fachlogik.
•Der Entwurf komplexer fachlicher
Zusammenhänge sollte auf einem Fachmodell
basieren.
Datum: 06.12.2011 Domain Driven Design Markus Goldbeck
10
10

11. Ubiquitous Language
Der Anfang und das Ende
Datum: 06.12.2011 Domain Driven Design Markus Goldbeck
11
11

12. Ubiquitous Language
• Zentrales und wichtigstes Element beim Modellieren
ist eine gemeinsame Sprache
=> Ubiquitous Language („Allgegenwärtige Sprache“)
• Gesprochen von allen (!) Team-Mitgliedern (inkl.
Kunden)
• Basis für alle Aktivitäten im Projekt
• Namensraum für alle Artefakte im Modell
Datum: 06.12.2011 Domain Driven Design Markus Goldbeck
12
12

13. Ubiquitous Language
• Wichtigfür die Etablierung eines einheitlichen
Domänen-Modells
• Ubiquitous Language => Modell =>
Implementierung (!)
• Änderungen in einem der drei -> Änderung in Allen
• Prinzipiell multilingual => besser englisch
• Consultingprozess
Datum: 06.12.2011 Domain Driven Design Markus Goldbeck
13
13

14. Ubiquitous Language
Begriff Bedeutung Übersetzung
Bestellung Summe aus verschiedenen Posten Order
Einheit bestehende aus Produkt,
Posten Row
Anzahl und Preis
Ort wo die Produkte aufgehoben
Lager Warehouse
werden - begrenzte Kapazität
Ein physikalischer oder virtueller
Produkt Artikel aus dem Angebot des Product
Kunden
Detaillierte Aufstellung der
Rechnung Invoice
Bestellung
Datum: 06.12.2011 Domain Driven Design Markus Goldbeck
14
14

15. Domain Model
Die Domäne und das zugehörige Modell
Datum: 06.12.2011 Domain Driven Design Markus Goldbeck
15
15

16. Was ist eine Domäne?
Domäne
Fachgebiet Problemfeld
Geschäftsfeld Persistenz
Eingabe/Ausgabe Einsatzbereich
GET/POST/COOKIES Infrastruktur
Datum: 06.12.2011 Domain Driven Design Markus Goldbeck
16
16

17. Was ist eine Domäne?
Domäne
Fachgebiet Problemfeld
Geschäftsfeld Persistenz
Eingabe/Ausgabe Einsatzbereich
GET/POST/COOKIES Infrastruktur
Datum: 06.12.2011 Domain Driven Design Markus Goldbeck
17
17

18. Wieso passen Domain Driven
Design und MVC so gut
zusammen?
Datum: 06.12.2011 Domain Driven Design Markus Goldbeck
18
18

19. Schichtenarchitektur
Quelle: Rau/Kurfürst - Extbase & FLuid, O‘Reilly
Datum: 06.12.2011 Domain Driven Design Markus Goldbeck
19
19

20. Domäne / Modell
• Um ein einheitliches Verständnis zwischen diesen
Gruppen (Domänenexperten und
Applikationsentwickler) zu schaffen, wird ein
Modell der Domäne etabliert
• Ein Model ist eine auf bestimmte Zwecke
ausgerichtete vereinfachende Beschreibung der
Wirklichkeit
Datum: 06.12.2011 Domain Driven Design Markus Goldbeck
20
20

21. Modellierung
Interativer, agiler Prozess
Domänenexperte und Dienstleister
Domänenmodell
Datum: 06.12.2011 Domain Driven Design Markus Goldbeck
21
21

22. Modellierung
Während dieser
Gespräche mit dem
Kunden entstehen
meist Diagramme, die
die Eigenschaften,
Funktionalitäten und
Beziehungen der
relevanten Bestandteile
des Problemfeldes in
Objekte verpacken und
deren Relationen
zueinanderdarstellen.
Datum: 06.12.2011 Domain Driven Design Markus Goldbeck
22
22

23. Domänen isolieren
Onlineshop
Bestellungen erzeugen Kunde benachrichtigen
Bestellungen aufgeben Rechnungen verschicken
Artikel in Warenkorb Lagerbestände
Bestellungen abschließen
Datum: 06.12.2011 Domain Driven Design Markus Goldbeck
23
23

24. Domänen isolieren
Artikel
Kunde
Rechnung
Onlineshop Lager Domänen
Warenkorb
Bestellung
Benachrichtigung
Datum: 06.12.2011 Domain Driven Design Markus Goldbeck
24
24

25. Bausteine für
Domain Driven Design
Datum: 06.12.2011 Domain Driven Design Markus Goldbeck
25
25

26. DDD Bausteine
Ubiquitous Language
Modell / Code
Entities Value Objects Services Module
Aggregates Factories Repositories
Datum: 06.12.2011 Domain Driven Design Markus Goldbeck
26
26

27. Was ist ein Domänenobjekt?
Die wichtigste Unterscheidung bei Modellelementen laut
Evans: Hat ein Element eine Identität oder nicht?
• Objekte müssen für eine spätere Unterscheidung
identifizierbar sein, um sie wieder finden zu können,
damit mit ihnen weitere Operationen durchgeführt
werden können. (Personen, Events, Konto, ...)
• Andere Objekte stellen nur die Repräsentation einer
Eigenschaft dar (Farben, Tags, ...). Deren Identität ist
bestimmt durch alle ihre Eigenschaften. Diese Objekte
sind unveränderlich
• Identität unveränderlich
Datum: 06.12.2011 Domain Driven Design Markus Goldbeck
27
27

28. Entities
Entities:
•eindeutig identifizierbare
Objekte
• eigene Identität
•Bsp: (Person mit
Benutzername oder
Personalausweisnummer)
•vergleichbar mit Primary
Keys MySQL
Datum: 06.12.2011 Domain Driven Design Markus Goldbeck
28
28

29. Value Objects
Value Objects:
• keine eigene Identität
• sind identifizierbar durch
alle ihre Attribute
•nach Erstellung
unveränderlich
Farbe weiß #FFFFFF Farbe weiß #FFFFF1
Datum: 06.12.2011 Domain Driven Design Markus Goldbeck
29
29

30. Services
Services:
• Verwendung für nicht an das Objekt gebundene
Funktionen oder
• Handling von mehreren Objekten
Beispiele:
• Geokoordinaten-Ermittlung für Adresse oder
• Überweisung zwischen zwei Konten,
• E-Mail Benachrichtigung,
• Importer/ Exporter
Datum: 06.12.2011 Domain Driven Design Markus Goldbeck
30

31. Objekt Lebenszyklus
Reale Welt In der Extbase /FLOW3 Welt
Quelle: Rau/Kurfürst - Extbase & FLuid, O‘Reilly
Datum: 06.12.2011 Domain Driven Design Markus Goldbeck
31

32. Repositories
• Technische Details
(der Persistenz) sollen
nicht in die Businesslogik
eindringen
• Dafür wurden
Repositories
„erschaffen“
Datum: 06.12.2011 Domain Driven Design Markus Goldbeck
32

33. Assoziationen
Assoziationen: Dynamische Beziehungen zwischen
Objekten als Abstraktion der realen Welt. UML als
verwendete Notation Welt.
bidirektional unibidirektional
ManyToMany ManyToMany Objekt
Objekt A Objekt B Objekt A
OneToMany OneToMany Objekt
Objekt A Objekt B Objekt A
OneToOne OneToOne Objekt
Objekt A Objekt B Objekt A
Datum: 06.12.2011 Domain Driven Design Markus Goldbeck
33

34. Assoziationen
vs.
bidirektional unidirektional
• Objekte sind direkt • Werden verwendet wenn
voneinander abhängig Daten nur von einem
• beide Objekte können Objekt benötigt werden,
nur zusammen • Ein Objekt kann ohne
vorkommen das andere existieren
Datum: 06.12.2011 Domain Driven Design Markus Goldbeck
34

35. Assoziationen
Generell ist es wichtig die Assoziationen so einfach wie möglich
zu halten, um die Implementierung nicht unnötig zu erschweren.
Am Anfang der Modellierung werden meist mehr „ManyToMany“-
Assoziationen verwendet als eigentlich gebraucht werden.
Folgende Fragen sollen die Verfeinerung der Assoziationen
erleichtern:
• Ist die „ManyToMany“-Assoziation wichtig in der
Anwendungsdomäne?
• Kann die Assoziation einseitig gemacht werden, da es eine
Hauptrichtung gibt, in der die Objekte abgefragt werden?
• Kann die Assoziation noch näher spezifiziert werden, z.B.
indem die einzelnen Elemente noch näher qualifiziert werden?
• Ist die Assoziation für die Kernfunktionalität überhaupt
Datum: 06.12.2011 Domain Driven Design Markus Goldbeck
35

36. Aggregate
• Viele Objekte auf derselben
Hierarchieebene
• Bestimmte Objekte machen einen
Teil eines größeren Objektes aus
• Ein Aggregat besitzt eine Wurzel
„AggregateRoot“
• Objekte außerhalb des Aggregates
dürfen nur auf die Wurzel
referenzieren, ansonsten kann die
Aggregate Root nicht die Integrität
der Objekte sicherstellen
• nur eine externe Identität -> muss
Entity sein
Quelle: Rau/Kurfürst - Extbase & FLuid, O‘Reilly
Datum: 06.12.2011 Domain Driven Design Markus Goldbeck
36

37. Aggregate
Datum: 06.12.2011 Domain Driven Design Markus Goldbeck
37

38. Aggregate
Datum: 06.12.2011 Domain Driven Design Markus Goldbeck
38

39. Factories
• Für erzeugen von Objekten
• Nur für in sich konsistente Aggregates
• Verwendung des Konstruktors vom AggregateRoot
• dadurch wird automatisch Konsistenz erreicht
• eigene Factory bei komplexeren Objeknetzen
<?php
class Car {
protected $engine;
protected $wheels;
public function __construct() {
$this->engine = new Engine();
$this->wheels[0] = new Wheel();
$this->wheels[1] = new Wheel();
$this->wheels[2] = new Wheel();
$this->wheels[3] = new Wheel();
}
}
?>
Datum: 06.12.2011 Domain Driven Design Markus Goldbeck
39

40. Zusammenfassung
Datum: 06.12.2011 Domain Driven Design Markus Goldbeck
40

41. Vorteile von
Domain Driven Design
Datum: 06.12.2011 Domain Driven Design Markus Goldbeck
41

42. Vorteile
• Besseres Verständnis der Domäne und somit des
Projektes
• FrüheEinbindung des Kunden und somit frühes
Feedback.
• Minderung des Projektrisikos
• Leichter zu erweitern
• Saubere Strukturierung des Codes; Zuständigkeiten
klar getrennt; Struktur von jedem verständlich
• Hohe Komplexität erst so wirklich handhabbar
• Zuständigkeiten klar getrennt
Datum: 06.12.2011 Domain Driven Design Markus Goldbeck
42

43. Quellen
und weitere Informationen
Datum: 06.12.2011 Domain Driven Design Markus Goldbeck
43

44. Quellen
Patrick Lobacher Folien und Vortrag
http://www.slideshare.net/plobacher/ddd-domain-
driven-design-typo3camp-stuttgart-2011
http://vimeo.com/25616882
Datum: 06.12.2011 Domain Driven Design Markus Goldbeck
44

45. Quellen Bücher
Datum: 06.12.2011 Domain Driven Design Markus Goldbeck
45

46. Quellen Bücher
Datum: 06.12.2011 Domain Driven Design Markus Goldbeck
46

47. Quellen
• Domain-Driven Design Community
domaindrivendesign.org
• Domain Driven Design Quickly (PDF)
www.infoq.com/minibooks/domain-driven-design-quickly
• DDD Step By Step (PDF)
thinkddd.com/assets/2/Domain_Driven_Design_-
_Step_by_Step.pdf
• http://flow3.typo3.org/documentation/guide/partii/
modeling.html
• http://de.wikipedia.org/wiki/Domain-Driven_Design
Datum: 06.12.2011 Domain Driven Design Markus Goldbeck
47

48. FRAGEN ?!
Datum: 06.12.2011 Domain Driven Design Markus Goldbeck
48

49. Vielen Dank!
Datum: 06.12.2011 Domain Driven Design Markus Goldbeck
49

50. Kontakt
Cross Content Media
Gesellschaft für Online Business Solutions mbH Twitter: @MarkusGoldbeck
Landshuter Allee 8 Email: mgoldbeck@cross-content.com
80637 München www.cross-content.com
Datum: 06.12.2011 Domain Driven Design Markus Goldbeck
50