Das Grund-Paradigma von Extbase und FLOW3 ist das sogenannte "Domain Driven Design" - der Vortrag zeigt was sich dahinter verbirgt und erklärt in einfachen Beispielen, warum es essentiell für Projektleiter, Programmierer und Kunden ist, dieses Paradigma zu verinnerlichen um Zeit, Mühe und letztlich Kosten zu sparen.
2. ÜBER PATRICK LOBACHER
• Patrick Lobacher (geb. Schuster) - GF typovision*
• 40 Jahre alt, verheiratet, wohnhaft in München
• Autor von 6 Fachbüchern und 26 Fachartikeln
zum Thema TYPO3 und Webentwicklung
• Certified TYPO3 Integrator seit 2009
• Mitglied in den TYPO3 Core-Teams:
Certification & Documentation
• Mitveranstalter des TYPO3camp München
• Speaker auf nationalen und internationalen Kongressen
• Dozent für führende Schulungsinstitute und die MVHS
(c) 2011 - typovision* | Domain-driven Design | Patrick Lobacher | www.typovision.de | 22.05.2011 2
3. ÜBER TYPOVISION*
• Münchner Fullservice-Agentur für digitale Kommunikation
• 9 Mitarbeiter (+ 8 aus festem Freelancer Pool)
• Geschäftsführer: Patrick Lobacher
• Spezialisiert auf TYPO3 seit 8 Jahren (Extbase/Fluid seit 2009)
• Agenturpräsentation unter: www.typovision.de/dieagentur
• Über 120 TYPO3-Projekte jeglicher Größenordnung - für Kunden wie:
(c) 2011 - typovision* | Domain-driven Design | Patrick Lobacher | www.typovision.de | 22.05.2011 3
4. Problem
Lösung
(c) 2011 - typovision* | Domain-driven Design | Patrick Lobacher | www.typovision.de | 22.05.2011 4
8. WAS IST DDD?
Eine Definition
(c) 2011 - typovision* | Domain-driven Design | Patrick Lobacher | www.typovision.de | 22.05.2011 7
9. DIE „ERFINDER“
JIMMY NILSSON ERIC EVANS MARTIN FOWLER
Easy setup of a TYPO3 demo site
(c) 2011 - typovision* | Domain-driven Design | Patrick Lobacher | www.typovision.de | 22.05.2011 8
10. DDD DEFINITION
Domain Driven Design ist ein von Eric Evans geprägter
Begriff für eine Anwendungsdomänen-getriebene
Herangehensweise an das Design komplexer
objektorientierter Software.
(c) 2011 - typovision* | Domain-driven Design | Patrick Lobacher | www.typovision.de | 22.05.2011 9
11. BASIS ANNAHME
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.
=> Explizit machen von impliziten Zusammenhängen
(c) 2011 - typovision* | Domain-driven Design | Patrick Lobacher | www.typovision.de | 22.05.2011 10
15. TYPISCHE PROJEKTE ?
• Unterschiedliches Verständnis von
domänenspezifischen Konzepten als einen wichtigen
Grund für die divergierenden Vorstellung der beiden
Gruppen Benutzer (Kunde) und Anwendungsentwickler
(Dienstleister)
(c) 2011 - typovision* | Domain-driven Design | Patrick Lobacher | www.typovision.de | 22.05.2011 14
16. DOMAIN MODEL
Die Domäne und das zugehörige Modell
(c) 2011 - typovision* | Domain-driven Design | Patrick Lobacher | www.typovision.de | 22.05.2011 15
19. DOMÄNE / MODELL
• Um also ein einheitliches Verständnis zwischen diesen
Gruppen (Domänenexperte und Applikationsentwickler)
zu schaffen, wird ein Modell der Domäne etabliert
• Ein Model ist eine auf bestimmte Zwecke ausgerichtete
vereinfachende Beschreibung der Wirklichkeit
(c) 2011 - typovision* | Domain-driven Design | Patrick Lobacher | www.typovision.de | 22.05.2011 18
21. MODELLIERUNG
• In der Regel entsteht
während dieser
Modellierungs-
Gespräche Diagramme,
die die Eigenschaften,
Funktionalitäten und
Beziehungen der
relevanten Bestandteile des Problemfeldes in Objekte
verpackt und deren Relationen darstellt.
(c) 2011 - typovision* | Domain-driven Design | Patrick Lobacher | www.typovision.de | 22.05.2011 20
24. UBIQUITOUS LANGUAGE
Den Turmbau von Babel verhindern
(c) 2011 - typovision* | Domain-driven Design | Patrick Lobacher | www.typovision.de | 22.05.2011 23
25. UBIQUITOUS LANGUAGE
• Zentrales, wichtigstes Element beim Modellieren ist eine
gemeinsame Sprache => Ubiquitous language
(„Allgegenwärtige Sprache“)
• Gesprochen von allen (!) Team-Mitgliedern (inkl. Kunde)
• Basis für alle Aktivitäten im Projekt
• Namensraum für alle Artefakte im Modell
(c) 2011 - typovision* | Domain-driven Design | Patrick Lobacher | www.typovision.de | 22.05.2011 24
26. UBIQUITOUS LANGUAGE
• Wichtig fü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
(c) 2011 - typovision* | Domain-driven Design | Patrick Lobacher | www.typovision.de | 22.05.2011 25
27. UL GLOSSAR
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 Product
Artikel aus dem Angebot des Kunden
Rechnung Detaillierte Aufstellung der Bestellung Invoice
(c) 2011 - typovision* | Domain-driven Design | Patrick Lobacher | www.typovision.de | 22.05.2011 26
28. BAUSTEINE FÜR DDD
Das Model aufbauen
(c) 2011 - typovision* | Domain-driven Design | Patrick Lobacher | www.typovision.de | 22.05.2011 27
30. DOMAIN OBJEKT
• Die wichtigste Unterscheidung die Evans zwischen
Modellelementen macht, ist ob ein Element eine Identität hat oder
nicht.
• Objekte müssen beispielsweise identifizierbar sein, um sie von
einander unterscheiden zu können oder zu einem späteren
Zeitpunkt wieder zu finden um weitere Operationen mit diesen
durchführen zu können (Personen, Events, Konto, ...)
• Andere Objekte stellen nur die Repräsentation einer Eigenschaft
dar (Farben, Tags, ...). Diese sind definiert durch alle
Eigenschaften.
(c) 2011 - typovision* | Domain-driven Design | Patrick Lobacher | www.typovision.de | 22.05.2011 29
31. DOMAIN OBJEKT
• Entities
• Identifizierbare Objekte, mit Identität
• Beispiel: Kunde selbst
• Value Objects
• Nicht identifizierbare Objekte,
ohne eigene Identität, nicht veränderbar
• Beispiel: Adresse bei einem Kunden
(c) 2011 - typovision* | Domain-driven Design | Patrick Lobacher | www.typovision.de | 22.05.2011 30
32. DOMAIN OBJEKT
• Services
• Nicht an das Objekt gebundene Funktionen oder
Handling von mehreren Objekten
• Beispiel:
Geokoordinaten-Ermittlung für Adresse oder
Überweisung zwischen zwei Konten
(c) 2011 - typovision* | Domain-driven Design | Patrick Lobacher | www.typovision.de | 22.05.2011 31
33. OBJEKT LEBENSZYKLUS
Richtiges Leben Domain-driven Design
Datenspeicher
Quelle: Rau/Kurfürst - Extbase & FLuid, O‘Reilly
(c) 2011 - typovision* | Domain-driven Design | Patrick Lobacher | www.typovision.de | 22.05.2011 32
34. REPOSITORIES
• Technische Details
(der Persistenz) sollen
nicht in die UL
eindringen
• Dafür wurden
Repositories
„erschaffen“
(c) 2011 - typovision* | Domain-driven Design | Patrick Lobacher | www.typovision.de | 22.05.2011 33
40. VORTEILE VON DDD
Warum kompliziert, wenn es auch einfach geht
(c) 2011 - typovision* | Domain-driven Design | Patrick Lobacher | www.typovision.de | 22.05.2011 39
41. VORTEILE
• Besseres Verständnis der Domäne
• Saubere Strukturierung des Codes
• Eleganter, schöner Code
• Code „sozusagen“ von jedem verständlich
• Hohe Komplexität erst so wirklich handhabbar
• Zuständigkeiten klar getrennt
• Leicht zu erweitern
• schnellere Time-to-market (TTM)
(c) 2011 - typovision* | Domain-driven Design | Patrick Lobacher | www.typovision.de | 22.05.2011 40