Domain-Driven Design in der Praxis

Domain Driven Design
in der Praxis
Michael Mirold, 22.10.2019

‣ "erfunden" 2004 durch Eric Evans
‣ Software-Modellierungs-Ansatz für fachlich
komplexe Anwendungen
‣ etabliert Pattern-Sprache
‣ große Fan-Gemeinde

DDD Grundideen
Fokus auf
"Core Domain"
Kollaboration von
Fachexperten
und Entwicklern
Etablierung einer
gemeinsamen
Sprache

testfabrik.com
7
Strategic
Design
Ev
Tactical
Design
Process &
Organization
Architecture &
Frameworks
DDD

STRATEGIC DESIGN - UBIQUITOUS LANGUAGE
"A language structured around the domain
model and used by all team members
within a bounded context to connect all the
activities of the team with the software."
UBIQUITOUS LANGUAGE

UBIQUITOUS
LANGUAGE
Developer
Tester
Business Analyst
Product Owner
Software-
Dokumentation
Requirements
User Interfaces +
Dokumentation
Source-Code
!!!
Team-
Kommunikation

IDEEN FÜR DIE PRAXIS
Aufbau eines Glossars
Vokabular für
User Stories
Verwendung im
Source-Code
‣Möglichst eindeutige Begri
ff
sde
fi
nitionen
‣Beziehungen zu anderen Begri
ff
en erläutern
‣nicht nur Substantive, auch Verhalten und
Eigenschaften
‣wie CRC-Karten

Vokabular für
User Stories
Verwendung im
Source-Code
‣Schon bei Anforderungsaufnahme "neue
Sprache" verwenden
‣Aufkommen anderer Begri
ff
e hinterfragen
und diskutieren

Vokabular für
User Stories
Verwendung im
Source-Code
‣Verwendung in
• Variablen- und Methodennamen
• Klassennamen
• APIs
• CSS-Klassen und HTML-Ids
‣Kontrolle in Code-Reviews

STRATEGIC DESIGN - BOUNDED CONTEXT
Streaming-Management
BEISPIEL ZDF:
WAS IST EIN STREAM?
FSK-Regeln
Geo-Location-
Regeln
Syncate
Formitäten
Playees
Formanden
Streamate
Meta-
Artefakte
?

WAS IST EIN STREAM?
FSK-Regeln
Geo-Location-
Regeln
Syncate
Formitäten
Playees
Formanden
Streamate
Meta-Artefakte
Streaming-Management
Untertitel
Teaser-Images
Teaser-
Texte
Social-
Media
Links
Formitäten
Autor
Assets
Produktions-Id
Mediathek CMS
Video-Codec
GOP-Size
Audio-
Codec
Bitrate
FPS
Aspect
Container
Pixel-Density
Encoding Cluster
Das universelle Domain-Modell
ist eine Illusion.
teure

"A description of a boundary (typically a
subsystem, or the work of a particular
team) within which a particular model is
de
fi
ned and applicable."
BOUNDED CONTEXT

STRATEGIC DESIGN - SUB DOMAINS
Core
Domain
Der Teil des Unternehmens,
um den sich alles dreht
Volle DDD-Power,
volle "Exzellenz"
Support
Domain
Weniger wichtig als
Core Domain
"Muss funktionieren"
(egal wie)
Generic
Subdomain
Generisch, wird
aber gebraucht
Wenn möglich,
zukaufen

STRATEGIC DESIGN - CONTEXT MAP
ZDF
Mediathek
Streaming
Logic
Encoding
Stream
Playout
Börse
Programm-
daten
Wetter
Sportdaten
Medien-
forschung
Teletext
Newsletter
Archiv
Chats und
Foren
Suche
Social
Media
Blog
Content-
Management
OHS/PL
ACL OHS
Supplier
3sat
Mediathek
Phoenix
Mediathek
Tivi
Mediathek
Supplier
Supplier
Supplier
Supplier
"API"

Pragmatisch bleiben
‣ DDD Tactical Design nur, wo es notwendig ist
‣ Support Domains auch per CRUD oder
Transaction Script
Nicht zu früh an Technik
denken

Pragmatisch bleiben
‣ Sub-Domains beschreiben "Problem Space",
d.h. das Business
‣ Bounded Contexts beschreiben "Solution
Space", d.h. die Realisierung
‣ Business-Anforderungen sind die Grundlage
Nicht zu früh an Technik
denken

TACTICAL DESIGN - ÜBERSICHT
Bounded Context "TestManagement"
Start TestRun Abort TestRun
Handle
DeviceReady
HandleTestRun
Timedout
Application
Service
Aggregate
TestRunStarted
TestRunFailed
TestRunFinished
TestRunTimedout
Domain Event
TestRun
Con
fi
guration
Ticket TestId
TestRun
State
UserId DeviceId
Value Object
Identity
TestScheduling
Strategy
Domain
Service
TestRun
Repository
TestRun
Factory
TestRun
Entity

TACTICAL DESIGN - AGGREGATES
AGGREGATES: Zentrales Konzept im Domänenmodell
Aggregate
Root
Entity
Value
Object
Entity
Value
Object
Entity
Value
Object

AGGREGATE: Zentrales Konzept im Domänenmodell
Aggregate
Root
Entity
Value
Object
Entity
Value
Object
Entity
Value
Object
‣ Aggregat: zusammenhängende Menge an
Objekten
‣ Aggregat muss zu jedem Zeitpunkt valide und
fachlich konsistent sein
➡ "Consistency Boundary"
‣ auf Aggregat kann von außen nur über
"Aggregate Root" zugegri
ff
en werden
• innere Objekte von außen nicht einzeln
ansprechbar
‣ Aggregat ist Basis für Transaktionalität

TIPPS AGGREGATE DESIGN
Aggregate klein halten
‣ Aggregate richtig schneiden ist schwierig
‣ Falsche Entscheidung kann u.a. Skalierbarkeit
verschlechtern
Eine Transaktion -
ein Aggregat
Aggregat-Referenz via Id
Aggregate gut wählen

‣ Sind Aggregate zu groß, drohen Concurrency-
Probleme
‣ Oftmals ein Zeichen für falsche Modellierung
‣ an die (wesentlichen) Usecases denken
Eine Transaktion -
ein Aggregat

‣ Verbessert Skalierbarkeit
‣ Spiegelt die Grundidee von Aggregaten wider
‣ "Daumenregel"
Eine Transaktion -
ein Aggregat

‣ Ids sind fachliche Modellobjekte
‣ keine Java-Referenzen
‣ keine Foreign-Key-Beziehungen in der DB
Eine Transaktion -
ein Aggregat
Aggregat-Persistenz
durch Document-Stores
bietet sich an

ARCHITECTURE - HEXAGONAL ARCHITECTURE
‣ Hexagon realisiert Bounded Context
‣ Alternative zu Schicht-Architektur
‣ Dependency-Inversion-Prinzip (Bob Martin):
"Abstractions should not depend on details.
Details (concrete implementations) should
depend on abstractions."
"High-level modules should not depend
on low-level modules. Both should
depend on abstractions (e.g. interfaces)."

POST /tests
1

2
create CreateTestCmd
Test
Repo
Test
Factory
Test
Repository
4
create new Test
6
add Test
7
publish
TestCreated
event
8
handle
TestCreated
event
9
send
noti
fi
cation
to user
5
validate new Test
execute CreateTestCmd
3

Bounded Context Hexagonal-Architektur
+
Gute Basis für Microservices
• hohe organisatorische Isolation (Conway's Law)
• hohe technische Isolation (Aggregate als
technische Transaktionsinseln)

ARCHITECTURE - CQRS
Anwendung modi
fi
zierender und lesender Call
rein modi
fi
zierender Call
rein lesender Call
ANWENDUNG MIT "NORMALEM" SCHICHTENMODELL
Remote Facade
Application Services
Business Logic
Data Access
Client 2
Client 3
Client 4
Client 5
Client 1

ARCHITECTURE - CQRS
EIN "NORMALES" SCHICHTENMODELL: PROBLEME
‣"One size
fi
ts it all"
‣Neue Clients benötigen oft neue
Sichten auf Daten
‣In
fl
ation von DTOs und Schnittstellen
‣Performance-Optimierung immer
schwieriger wegen unterschiedlicher
Anforderungen
‣Changes am Model immer aufwändiger
Remote Facade
Application
Services
Business Logic
Data Access
Client 1
Client 2
Client 3
Client 4
Client 5

ARCHITECTURE - CQRS
CQRS: Trennung von Command- und Query-Models
Application Services
Business Logic
Data Access
Remote Facade
Client 1
Client 2
Client 3
Client 4
Client 5
Remote Facade
Query Service
Data Access
Remote Facade
Query Service
Data Access
Remote Facade
Query Service
Data Access
Command Model
Query Model B Query Model C Query Model D
Query Model A
Remote Facade
Query Service
Data Access
DomainEvent DomainEvent

ARCHITECTURE - CQRS
CQRS: Command / Query Responsibility Segregration
Vorteile
‣ Read-Models können extrem einfach sein,
z.B.
• vollständig denormalisierte SQL-
Tabellen (bzw. Materialized Views)
• ... oder Document Stores
‣ Read-Models erlauben einfache
Skalierung und Performance-Optimierung
‣ möglicherweise komplexe Mechanik:
Messaging, Apache Kafka etc.
‣ nur "eventual consistency": muss
auf Applikations-Ebene kompensiert
werden
‣ Full-Rebuild von Query-Models muss
eingeplant werden und oft teuer
(analog zu Seach-Feeder)
Nachteile

ARCHITECTURE - BEISPIELARCHITEKTUR

WIE GEHTS WEITER?
Functional
DDD
DDD und
Prozess
Event
Sourcing

LITERATUR
💆 👍
👨🔬 🔧 ⏲ ⏲
😍 👨🔬
👍 👍

DANKE FÜR EURE
AUFMERKSAMKEIT :-)

Domain-Driven Design in der Praxis

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Domain-Driven Design in der Praxis

Ähnlich wie Domain-Driven Design in der Praxis (20)

Domain-Driven Design in der Praxis