Domain Driven Design

  • 3,168 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
3,168
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
0
Comments
0
Likes
5

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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? DrivenDatum: 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 VorstellungDatum: 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 FOWLERDatum: 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 EndeDatum: 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 ModellDatum: 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 • ConsultingprozessDatum: 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 BestellungDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 14 14
  • 15. Domain Model Die Domäne und das zugehörige ModellDatum: 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 InfrastrukturDatum: 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 InfrastrukturDatum: 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‘ReillyDatum: 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 WirklichkeitDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 20 20
  • 21. Modellierung Interativer, agiler Prozess Domänenexperte und Dienstleister DomänenmodellDatum: 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ßenDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 23 23
  • 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. Bausteine für Domain Driven DesignDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 25 25
  • 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. 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. 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. 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. 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. 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. 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 ADatum: 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 existierenDatum: 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 überhauptDatum: 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‘ReillyDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 36
  • 37. AggregateDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 37
  • 38. AggregateDatum: 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. ZusammenfassungDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 40
  • 41. Vorteile von Domain Driven DesignDatum: 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 getrenntDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 42
  • 43. Quellen und weitere InformationenDatum: 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/25616882Datum: 06.12.2011 Domain Driven Design Markus Goldbeck 44
  • 45. Quellen BücherDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 45
  • 46. Quellen BücherDatum: 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_DesignDatum: 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.comDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 50