Der moderne Weg, um Extensions für TYPO3 zu schreiben, führt letztlich zu Extbase und Fluid. Während Extbase/Fluid/FLOW3 im Grunde "nur" technische Lösungen bzw. Umsetzungen sind - liegt diesen ein Paradigma (eine Denkweise) zu Grunde, welches sich "Domain-driven Design" nennt. Hier steht die Domäne (Problemfeld, Anwendungsgebiet) des Kunden im Fokus und nicht die konkrete technische Realisierung. Der Vortrag zeigt, was alles hinter diesem Paradigma steckt, zeigt ausführlich die Grundlagen auf und stellt dar, warum diese Denkweise die Arbeit von Projektmanagern, Kunden und Programmiereren grundlegend verändert und letztlich verbessert
2. ÜBER TYPOVISION
• Patrick Lobacher
• Geschäftsführer typovision*
• Premium Online Business Solutions - mit TYPO3
• Gegründet vor 16 Jahren (net-o-graphic / typofaktum)
• Über 800 abgeschlossene Projekte, >100 mit TYPO3
• Kunden: Vodafone, Finanzscout 24, AGIP, Contraco, Siemens, Arbeitsamt
München, Langenscheidt, Motorola, Integralis, u.v.a.m
• Aktiv in der Community: TYPO3camp, Certification und Documentation Team
• Autor zahlreicher Fachbücher und Artikel:
(c) 2010 - typovision* | TYPO3camp | Domain-driven Design | Patrick Lobacher | www.typovision.de | 12.09.2010 2
3. WAS IST DDD?
Eine Definition
(c) 2010 - typovision* | TYPO3camp | Domain-driven Design | Patrick Lobacher | www.typovision.de | 12.09.2010 3
4. DIE „ERFINDER“
JIMMY NILSSON ERIC EVANS MARTIN FOWLER
Easy setup of a TYPO3 demo site
(c) 2010 - typovision* | TYPO3camp | Domain-driven Design | Patrick Lobacher | www.typovision.de | 12.09.2010 4
5. 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) 2010 - typovision* | TYPO3camp | Domain-driven Design | Patrick Lobacher | www.typovision.de | 12.09.2010 5
6. 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) 2010 - typovision* | TYPO3camp | Domain-driven Design | Patrick Lobacher | www.typovision.de | 12.09.2010 6
10. 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) 2010 - typovision* | TYPO3camp | Domain-driven Design | Patrick Lobacher | www.typovision.de | 12.09.2010 10
11. DOMAIN MODEL
Die Domäne und das zugehörige Modell
(c) 2010 - typovision* | TYPO3camp | Domain-driven Design | Patrick Lobacher | www.typovision.de | 12.09.2010 11
12. DOMÄNE
• Was ist eine Domäne?
Ein abgrenzbares Problemfeld, Fachgebiet,
Geschäftsfeld bzw. Einsatzbereich
NICHT!!!!: Infrastruktur, wie Persistenz, Templating,
Eingabe, ...
(c) 2010 - typovision* | TYPO3camp | Domain-driven Design | Patrick Lobacher | www.typovision.de | 12.09.2010 12
13. 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) 2010 - typovision* | TYPO3camp | Domain-driven Design | Patrick Lobacher | www.typovision.de | 12.09.2010 13
14. BEISPIEL MODELL
• Quelle: http://www.holz-solar-haus.de/
(c) 2010 - typovision* | TYPO3camp | Domain-driven Design | Patrick Lobacher | www.typovision.de | 12.09.2010 14
16. UBIQUITOUS LANGUAGE
Den Turmbau von Babel verhindern
(c) 2010 - typovision* | TYPO3camp | Domain-driven Design | Patrick Lobacher | www.typovision.de | 12.09.2010 16
17. 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) 2010 - typovision* | TYPO3camp | Domain-driven Design | Patrick Lobacher | www.typovision.de | 12.09.2010 17
18. 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) 2010 - typovision* | TYPO3camp | Domain-driven Design | Patrick Lobacher | www.typovision.de | 12.09.2010 18
19. UL / MODELLIERUNG
• In der Regel entsteht während dieser
Modellierungs-Gespräche ein (UML)
Diagramm, das die Eigenschaften,
Funktionalitäten und Beziehungen
der relevanten Bestandteile des
Problemfeldes in Objekte verpackt
und deren Relationen darstellt.
(c) 2010 - typovision* | TYPO3camp | Domain-driven Design | Patrick Lobacher | www.typovision.de | 12.09.2010 19
20. BAUSTEINE FÜR DDD
Das Model aufbauen
(c) 2010 - typovision* | TYPO3camp | Domain-driven Design | Patrick Lobacher | www.typovision.de | 12.09.2010 20
21. DOMAIN OBJEKT
(c) 2010 - typovision* | TYPO3camp | Domain-driven Design | Patrick Lobacher | www.typovision.de | 12.09.2010 21
22. 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) 2010 - typovision* | TYPO3camp | Domain-driven Design | Patrick Lobacher | www.typovision.de | 12.09.2010 22
23. DOMAIN OBJEKT
• Value Objects
• Nicht identifizierbare Objekte,
ohne eigene Identität
• Beispiel: Adresse bei einem Kunden
• Entities
• Identifizierbare Objekte, mit Identität
• Beispiel: Kunde selbst
(c) 2010 - typovision* | TYPO3camp | Domain-driven Design | Patrick Lobacher | www.typovision.de | 12.09.2010 23
24. 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) 2010 - typovision* | TYPO3camp | Domain-driven Design | Patrick Lobacher | www.typovision.de | 12.09.2010 24
26. REPOSITORIES
• Technische Details
(der Persistenz) sollen
nicht in die UL
eindringen
• Dafür wurden
Repositories
erschaffen
(c) 2010 - typovision* | TYPO3camp | Domain-driven Design | Patrick Lobacher | www.typovision.de | 12.09.2010 26
31. VORTEILE VON DDD
Warum kompliziert, wenn es auch einfach geht
(c) 2010 - typovision* | TYPO3camp | Domain-driven Design | Patrick Lobacher | www.typovision.de | 12.09.2010 31
32. 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) 2010 - typovision* | TYPO3camp | Domain-driven Design | Patrick Lobacher | www.typovision.de | 12.09.2010 32