• Save
Domain Driven Design
Upcoming SlideShare
Loading in...5
×
 

Domain Driven Design

on

  • 3,402 views

 

Statistics

Views

Total Views
3,402
Views on SlideShare
1,884
Embed Views
1,518

Actions

Likes
5
Downloads
0
Comments
0

7 Embeds 1,518

http://flow3.typo3.org 1258
http://www.mfug.de 119
http://www.mtug.de 97
http://mfug.de 37
http://dev.phoenixtypo3org 3
http://translate.googleusercontent.com 2
http://new.finix.com 2
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Domain Driven Design Domain Driven Design Presentation Transcript

  • Domain Driven Design 1
  • Gründe für Domain Driven Design?Datum: 06.12.2011 Domain Driven Design Markus Goldbeck 2 2
  • Typische Projekte? DrivenDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 3 3
  • Typische Projekte?Datum: 06.12.2011 Domain Driven Design Markus Goldbeck 4 4
  • Grundproblem Vorstellung Kunde Unterschiedliches Verständnis der domänenspezifischen Konzepte VorstellungDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 5 5
  • Was ist Domain Driven Design?Datum: 06.12.2011 Domain Driven Design Markus Goldbeck 6 6
  • 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
  • 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
  • Wer hat‘s erfunden? JIMMY NILSSON ERIC EVANS MARTIN FOWLERDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 9 9
  • 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
  • Ubiquitous Language Der Anfang und das EndeDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 11 11
  • 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
  • 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
  • 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
  • Domain Model Die Domäne und das zugehörige ModellDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 15 15
  • 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
  • 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
  • Wieso passen Domain Driven Design und MVC so gut zusammen?Datum: 06.12.2011 Domain Driven Design Markus Goldbeck 18 18
  • Schichtenarchitektur Quelle: Rau/Kurfürst - Extbase & FLuid, O‘ReillyDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 19 19
  • 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
  • Modellierung Interativer, agiler Prozess Domänenexperte und Dienstleister DomänenmodellDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 21 21
  • 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
  • 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
  • Domänen isolieren Artikel Kunde Rechnung Onlineshop Lager Domänen Warenkorb Bestellung BenachrichtigungDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 24 24
  • Bausteine für Domain Driven DesignDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 25 25
  • DDD Bausteine Ubiquitous Language Modell / Code Entities Value Objects Services Module Aggregates Factories RepositoriesDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 26 26
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • AggregateDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 37
  • AggregateDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 38
  • 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
  • ZusammenfassungDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 40
  • Vorteile von Domain Driven DesignDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 41
  • 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
  • Quellen und weitere InformationenDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 43
  • 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
  • Quellen BücherDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 45
  • Quellen BücherDatum: 06.12.2011 Domain Driven Design Markus Goldbeck 46
  • 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
  • FRAGEN ?!Datum: 06.12.2011 Domain Driven Design Markus Goldbeck 48
  • Vielen Dank!Datum: 06.12.2011 Domain Driven Design Markus Goldbeck 49
  • 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