Domain Driven Design

4,005 views
3,901 views

Published on

Published in: Technology
0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,005
On SlideShare
0
From Embeds
0
Number of Embeds
1,544
Actions
Shares
0
Downloads
0
Comments
0
Likes
5
Embeds 0
No embeds

No notes for slide

Domain Driven Design

  1. 1. Domain Driven Design 1
  2. 2. Gründe für Domain Driven Design?Datum: 06.12.2011 Domain Driven Design Markus Goldbeck 2 2
  3. 3. Typische Projekte? DrivenDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 3 3
  4. 4. Typische Projekte?Datum: 06.12.2011 Domain Driven Design Markus Goldbeck 4 4
  5. 5. Grundproblem Vorstellung Kunde Unterschiedliches Verständnis der domänenspezifischen Konzepte VorstellungDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 5 5
  6. 6. Was ist Domain Driven Design?Datum: 06.12.2011 Domain Driven Design Markus Goldbeck 6 6
  7. 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. 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. 9. Wer hat‘s erfunden? JIMMY NILSSON ERIC EVANS MARTIN FOWLERDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 9 9
  10. 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. 11. Ubiquitous Language Der Anfang und das EndeDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 11 11
  12. 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 ModellDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 12 12
  13. 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 • ConsultingprozessDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 13 13
  14. 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 BestellungDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 14 14
  15. 15. Domain Model Die Domäne und das zugehörige ModellDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 15 15
  16. 16. Was ist eine Domäne? Domäne Fachgebiet Problemfeld Geschäftsfeld Persistenz Eingabe/Ausgabe Einsatzbereich GET/POST/COOKIES InfrastrukturDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 16 16
  17. 17. Was ist eine Domäne? Domäne Fachgebiet Problemfeld Geschäftsfeld Persistenz Eingabe/Ausgabe Einsatzbereich GET/POST/COOKIES InfrastrukturDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 17 17
  18. 18. Wieso passen Domain Driven Design und MVC so gut zusammen?Datum: 06.12.2011 Domain Driven Design Markus Goldbeck 18 18
  19. 19. Schichtenarchitektur Quelle: Rau/Kurfürst - Extbase & FLuid, O‘ReillyDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 19 19
  20. 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 WirklichkeitDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 20 20
  21. 21. Modellierung Interativer, agiler Prozess Domänenexperte und Dienstleister DomänenmodellDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 21 21
  22. 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. 23. Domänen isolieren Onlineshop Bestellungen erzeugen Kunde benachrichtigen Bestellungen aufgeben Rechnungen verschicken Artikel in Warenkorb Lagerbestände Bestellungen abschließenDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 23 23
  24. 24. Domänen isolieren Artikel Kunde Rechnung Onlineshop Lager Domänen Warenkorb Bestellung BenachrichtigungDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 24 24
  25. 25. Bausteine für Domain Driven DesignDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 25 25
  26. 26. DDD Bausteine Ubiquitous Language Modell / Code Entities Value Objects Services Module Aggregates Factories RepositoriesDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 26 26
  27. 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änderlichDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 27 27
  28. 28. Entities Entities: •eindeutig identifizierbare Objekte • eigene Identität •Bsp: (Person mit Benutzername oder Personalausweisnummer) •vergleichbar mit Primary Keys MySQLDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 28 28
  29. 29. Value Objects Value Objects: • keine eigene Identität • sind identifizierbar durch alle ihre Attribute •nach Erstellung unveränderlich Farbe weiß #FFFFFF Farbe weiß #FFFFF1Datum: 06.12.2011 Domain Driven Design Markus Goldbeck 29 29
  30. 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/ ExporterDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 30
  31. 31. Objekt Lebenszyklus Reale Welt In der Extbase /FLOW3 Welt Quelle: Rau/Kurfürst - Extbase & FLuid, O‘ReillyDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 31
  32. 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. 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 ADatum: 06.12.2011 Domain Driven Design Markus Goldbeck 33
  34. 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 existierenDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 34
  35. 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 überhauptDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 35
  36. 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‘ReillyDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 36
  37. 37. AggregateDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 37
  38. 38. AggregateDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 38
  39. 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. 40. ZusammenfassungDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 40
  41. 41. Vorteile von Domain Driven DesignDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 41
  42. 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 getrenntDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 42
  43. 43. Quellen und weitere InformationenDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 43
  44. 44. Quellen Patrick Lobacher Folien und Vortrag http://www.slideshare.net/plobacher/ddd-domain- driven-design-typo3camp-stuttgart-2011 http://vimeo.com/25616882Datum: 06.12.2011 Domain Driven Design Markus Goldbeck 44
  45. 45. Quellen BücherDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 45
  46. 46. Quellen BücherDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 46
  47. 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_DesignDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 47
  48. 48. FRAGEN ?!Datum: 06.12.2011 Domain Driven Design Markus Goldbeck 48
  49. 49. Vielen Dank!Datum: 06.12.2011 Domain Driven Design Markus Goldbeck 49
  50. 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.comDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 50

×