Patterns of domain driven design

Patterns of Domain-Driven Design

I © NETFORMIC GmbH I
@afoeder
2

I © NETFORMIC GmbH I3
Domain-Driven Design
Gleichnamiges Buch
von Eric Evans aus 2003
Bild: Google Books

2003: Evans’ Domain-Driven Design erscheint
Bilder: Google Books
2010: Zukunftssichere TYPO3-Extensions
mit Extbase und Fluid erscheint und macht
DDD der TYPO3-Welt bekannt
2013: Implementing Domain-Driven Design
von Vaughn Vernon gibt Praxisrat
2016: Domain-Driven Design Distilled
[Vernon] Taschenbuch mit DDD in Kurzform
2006/07: Lemke und Dambekalns beginnen
die Arbeit an „FLOW3“1, stark das DDD-
Paradigma stützend
1: https://www.heise.de/developer/artikel/Robert-Lemke-im-Interview-zu-FLOW3-1362225.html?seite=3

• Herangehensweise zur Softwareentwicklung

• Streng ausgerichtet auf die Fachlichkeit
der Domäne (das Business, eben)

Ubiquitous Language
ubiquitous (adv): allgegenwärtig
7 Bild: Adrian Föder, CC BY-SA 4.0

Ubiquitous Language (UL)
Streng gemeinsam genutzte „Sprache“1
zwischen allen Beteiligten
1 gemeint ist eher „Vokabular“
• DOMAIN EXPERT (Kunde, „PO“)
• Entwickler
• Projektleiter
• …

Ziel:
Gemeinsames, tiefes Verständnis etablieren

• UL im Regelfall vom DOMAIN EXPERT geprägt
• Entwickelt sich während der Arbeit damit
weiter (vgl. Sprache)

Entwickler müssen direkt mit dem
Domain Expert sprechen!
Jedes Mal!
Notfalls mit Bestechung!
Bild: Implementing Domain-Driven Design, [Vernon2013], p30, Screenshot aus Google Books

Entwickler: häufig zu technisch
in Denke und Kommunikation
AUTRAG!
KOMMISSION!TBL_ORDERS!
TBL_PICKUP!

Business
=
Model
=
Code
Daher Achtung: Tabellen sind nur
technische Notwendigkeit
ORMs übernehmen diese Arbeit

Entities
Mehr als die Summe ihrer Eigenschaften
15 Bild: https://commons.wikimedia.org/wiki/File:Macro_Fingerprints.jpg v. D. Sharon Pruitt

Entities
ENTITIES haben eine Identität

Entities
Bleiben während ihres Lifecycles
immer dieselben

Entities
• Höhe: 53 cm
• Gewicht: 3,3 kg
• Höhe: 158 cm
• Gewicht: 52,7 kg
• Höhe: 181 cm
• Gewicht: 81,5 kg
• Höhe: 178 cm
• Gewicht: 72 kg
Peter:

Entities
Identifier?

Value Objects
Eigenschaften sind alles
21 Bild: https://commons.wikimedia.org/wiki/File:Petite_Picasso_110324-F-LA132-004.jpg

Value
Objects
Bild: https://pixabay.com/en/crayons-coloring-book-coloring-book-1445053/
GIB MIR MAL DIE
GELB!

Value Objects
VALUE OBJECTS haben
keine konzeptionelle Identität

Value
Objects
Bild: https://www.pexels.com/photo/baked-goods-bakery-bread-breakfast-162996/
EIN HELLES
MIT
WENIG SALZ
BITTE!

Value Objects
VALUE OBJECTS sind
immutable, also unveränderlich!

Value Objects
ENTITY oder VALUE OBJECT?

Bild: https://www.pexels.com/photo/gray-auto-bill-counter-164688/

Bild: https://www.pexels.com/photo/close-up-of-50-euro-money-248933/

Entity oder Value Object
Why care?
Warum nicht auf Verdacht
immer Identity?

Identities managen ist expensive.

Bild: https://www.pexels.com/photo/top-angle-photo-of-child-holding-pencil-while-drawing-female-angel-playing-wind-instrument-707193/

Bild: https://www.pexels.com/photo/bank-note-banknote-banknotes-bill-259251/

In verteilten Systemen wäre zusätzlich
ein ANTI CORRUPTION LAYER erforderlich

Entities und Value Objects
Technische Betrachtungen

Entities in Doctrine sind…

Every PHP object that you want to save in the database using Doctrine is called an “Entity”. The
term “Entity” describes objects that have an identity over many independent requests. This
identity is usually achieved by assigning a unique identifier to an entity.

Aber Value Objects haben doch keine Identifier?

In Doctrine: Embeddables

Value Objects mit Embeddables

Felder der Embedded-Klassen werden schlicht daneben angefügt
Durch den Prefix können diese Embeddables wiederverwendet werden
(Address, Money, PersonName, …)
Prefix kann bei Bedarf geändert oder entfernt werden:

Domain Logic in die Models!

Entities und VOs tun Dinge.
wissen Dinge.
können Dinge.

Wenn nicht, hat man ein
Anemic Domain Model.
which is bad.

Anemic Domain Models

• Tell, don’t ask.
• Models sind keine dummen Datenbeutel.
• Methoden sollen Business-Fälle reflektieren
und selbst ihre Integrität bewahren.

Business-Case-Beispiel:
Kunde zieht um

• Vielleicht kann er ja garnicht einfach „umziehen“?
(Kabelanschluss erst prüfen oder so)
• Vielleicht müssen Drittsysteme
benachrichtigt werden

Services
»Sometimes it just isn’t a thing«
60
Bild: https://www.pexels.com/photo/coffee-shop-702251/

Services kommen in Frage, wenn…
61
• die Operation nicht naturgemäß eher einer ENTITY oder einem VALUE OBJECT
obliegt
• die Operation stateless ist
• die Operation Teil der UBIQUITOUS LANGUAGE ist

Aggregates
Zusammenhalt
62
Bild: https://www.pexels.com/photo/binding-books-bound-colorful-272980/

Aggregates
Bild: https://www.valueflo.ws/specification/diagrams/uml.html

Aggregates
Aggregate sind eine Gruppierung aus Objekten, die
miteinander in Verbindung stehen
Ein Aggregat hat eine Wurzel und eine Grenze

Aggregates

Aggregates
Der Inhaber ist außerhalb des Kontexts einer
Apotheke völlig irrelevant.

Aggregates
• „Eine Apotheke hat
mindestens einen Inhaber“
• „Nur eine Apo der
Handelsform oHG darf
mehrere Inhaber haben,
die dann allesamt „e.K.“
sein müssen“
Bild: https://www.pexels.com/photo/adult-blur-boss-business-288477/

Aggregates
„Framework“
DB
“Repository”
(“Doctrine”)
“Templating”
(“macht HTML”)
“Controller”
(“macht PHP”)(“macht PHP”)

Aggregates

Aggregates
Untestbar (Controller: viel Unwesentliches)
Core-Business-Konzept ist tief vergraben
irgendwo in einem Controller in prozeduralen if-
else-Anweisungen
Hohe code duplication bei Wiederkehren der
Anforderung

Aggregates
Aggregates stellen Datenintegrität
ihrer Members sicher.

Aggregates

Aggregates
Apotheke ändert Unternehmensform?

Aggregates
KEIN Anemic Domain Model mehr!

Aggregates
Prinzipiell:
Die Anwendung (im Business-Sinne!) benötigt keinen
expliziten Zugriff auf die Entities eines Aggregates
Nur Aggregate Roots haben ein REPOSITORY!

Aggregates
Hof-Apotheke Tests: • Bluttests
• Legionellen
• Haarmineralanalyse
Homöopathie: • Schüssler-Salze
• Anthroposophische
Arzneimittel

Repositories
Abgelegtes wiederbekommen
79
Bild: Screenshot Raiders of the Lost Ark (1981) von Steven Spielberg via Netflix

Repositories
„Mit Repositories bekomme ich meine
Daten aus der Datenbank“
– ein Entwickler

Repositories

Repositories
„Über Repositories erhalte ich Referenzen
auf Objekte zurück.“

Repositories
• Repositories sind eine dünne Schicht
zwischen Domain (Layer) und
Persistenz
• Repositories sind für je eine Entity
(besser: Aggregate Root) zuständig
• Repositories enthalten keine
(Business-)Logik!
• (nicht einmal) Validierung.

Repositories
Doctrine bietet bereits (magische)
Repositories
Mein Tipp: dennoch (Stub) erstellen für
Typsicherheit

Ausblick
wait, there is more!
85 Bild: https://www.pexels.com/photo/grayscale-photo-of-yachts-on-body-of-water-under-cloudy-sky-698379/

Domains, Subdomains & Bounded Contexts
Big Picture
86

Bounded Contexts
Product
Invoice
Order
Customer
Rating
Inventory
Category
Searching
Newsletter
Shipping

Bounded Contexts
Catalog
Models
Product Category

Bounded Contexts
Inventory
Models
Product Warehouse
Rack

Bounded Contexts
Es gibt mehr als eine Klasse, die ein Produkt repräsentiert.

Context Map

Kommunikation über Messaging
Domain Events
92

The heck are they?
Microservices
93

Microservices
Die Geister scheiden sich

Literatur
95

Patterns of domain driven design

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Patterns of domain driven design

Ähnlich wie Patterns of domain driven design (20)

Patterns of domain driven design

Hinweis der Redaktion