Its all about the domain honey

WPS - Workplace Solutions GmbH //// Hans-Henny-Jahnn-Weg 29 //// 22085 HAMBURG
IT’S ALL ABOUT THE DOMAIN, HONEY -
Erfahrungen aus 10 Jahren Domain Driven Design
Dr. Carola Lilienthal, cl@wps.de, @cairolali
www.wps.de

30.03.2017 //// Seite 3WPS - Workplace Solutions GmbH
Software-
Architektur
Anforderungs-
ermittlung
Leitstand und
Interaktion
Individual-
software
Business-Software,
die Spaß macht!
WPS – Workplace Solutions GmbH

Dr. Carola Lilienthal
Geschäftsführerin
cl@wps.de
www.wps.de
+49 40 229 499-0
+49 40 229 499-299
+49 170 184 77 11
Diplom-Informatikerin
@cairolali
a @cairolali
cl@wps.de
www.llsa.de

Schulung Domain-Driven Design
Modul für Advanced Level
wps.de/ddd

WIR SIND PROGRAMMIERER...

... UND WIR LIEBEN TECHNIK

SOFTWARE != SELBSTZWECK
Software ist ein Mittel zum Zweck
Kein Selbstzweck
Das Ziel ist das Ziel

SOFTWARE UND DOMÄNE
Schreibe Software, die tief
in der Domäne verwurzelt
ist!
Software
Domäne

DOMAIN DRIVEN DESIGN ANWENDEN
 Zu Beginn eines Softwareprojekts:
 Fokussiere die Domäne in der die Software eingesetzt wird
 Wie erschafft man Software, die zu einer Domäne passt?
 Begreife Software als Reflektion
der Domäne
 Lasse Kernkonzepte und
Elemente der Domäne
in die Software einfließen
 Realisiere ihre
Zusammenhänge
 Erstelle ein Domänenmodell

TECHNISCHE SPRACHE
X
Class
Database
Server
Client
O/R-Mapping
Inheritance
A
B
Method
Interface
Linux
Windows
Eclipse
Visual Studio

DOMÄNEN-SPRACHE
Container
Containernummer
4300
Kran
Twistlock
Konnossement
Beispiel: Hafen

Fach-
sprache
Techno
Babble
?
UBIQUITOUS LANGUAGE

Fach-
sprache
Techno
Babble
Fach-
sprache
UBIQUITOUS LANGUAGE

Fach-
sprache
Techno
Babble
UBIQUITOUS LANGUAGE

Techno
Babble
Fach-
sprache
UBIQUITOUS LANGUAGE

Fach-
sprache
{
Techno
Babble
}
?
UBIQUITOUS LANGUAGE

Fach-
sprache
{
Fach-
sprache
}
UBIQUITOUS LANGUAGE

UBIQUITOUS LANGUAGE
 Verwende die gemeinsame Sprache in..
 der Kommunikation
 mündlich
 schriftlich
 grafisch
 im Code
 Im Grunde genommen überall
 Deswegen nennt sich die Fachsprache allgegenwärtig.

SPRACHE TAUCHT NICHT EINFACH AUF
 Es braucht Wochen bis Monate...
 harter Arbeit
 und scharfem Fokus
 … um die Schlüsselkonzepte offenzulegen.
 Die ersten Wörter einer allgemeinen Fachsprache kommen
üblicherweise direkt aus der Domäne
 Im Laufe der Entwicklung werden neue Begriffe definiert
und hinzugefügt

DOMÄNEN-SPRACHE
Brett
König
Figuren
Spieler
Schachuhr

ALLGEGENWÄRTIGE FACHSPRACHE
Brett
Figuren
Spieler
Nichtmenschlicher
Spieler

SPRACHEN SIND LEBENDIG
 Experimentiere mit alternativen Ausdrucksformen
 Das Modell und die Sprache entwickeln sich weiter
 Überarbeite dann den Code
 Benenne Klassen, Methoden, Module
 Entspreche dem neuen Modell
 Eine Sprache will gesprochen werden:
 Beseitige Unklarheiten durch Konversation

GLOSSAR
 Fachsprache der Benutzer/Ubiquitous Language
• bereits existierende Begriffe
• rekonstruierte Begriffe
• neue Begriffsbildungen
•Wer tut was damit wozu?
 Kernkonzepte
 Wichtiger am Anfang des Projektes
 Oft Wegwerfprodukt

WIE LERNEN WIR DIE FACHLICHKEIT?
 Durch die Fachexperten (domain experts)
 Sie haben das Wissen
 Worum es bei ihrer Arbeit geht
 Wo die Software sie unterstützen kann
 Auch wenn sie das Wissen nicht selbständig aufschreiben bzw. abstrahieren
können
 Wer die Fachlichkeit nicht
versteht, kann ihr nicht
helfen
 Softwareentwickler und
Fachexperten bilden
zusammen das Team

WIE KOMMEN WIR AN DAS WISSEN DER FACHEXPERTEN?
Welche Techniken gibt es?
 Interviews
 Use Cases + Szenarien
 Workshops
 Event Storming
 Domain Storytelling
Das wollen wir
extrahieren!
Fach-
wissen

WORKSHOPS MIT ANWENDERN UND PRODUCT OWNERN
“Georgia?” by The Library of Congress, flickr.com
• Teilnehmer aus verschiedenen Bereichen (Business, IT, Management, …)
• ein Moderator für den Workshop
 direktes Feedback von allen Beteiligten

EVENT STORMING
 Eine Methode um Geschäftsprozesse zu modellieren
Modelliert werden:
Domain Events
Commands
Acteure
Aggregate

DOMAIN STORYTELLING
www.domainstorytelling.org
Modelliert werden:
Akteure
Gegenstände
Handlungen

TAKTISCHES UND STRATEGISCHES MODELLIEREN
 DDD gibt Anleitung für Modellierung im Großen und im Kleinen
 Strategisches Modellieren
 Teile die Domäne in getrennte Bounded Contexts auf
 Jeder BC hat sein eigenes Fachmodell und seine eigene Allgegenwärtige
Sprache
 Context Mapping hilft die Beziehungen zwischen Bounded Contexts zu
verstehen
 Taktisches Modellieren
 Innerhalb eines Bounded Context
 Building Blocks: Entity, Value Object,
Aggregate, Service, Repository, Factory

GROSSE PROJEKTE
 Erfordern mehrere Teams
 Entwicklung findet parallel statt
 Jedes Team korrespondiert mit einem Teil des Modells
 Ein großes Modell?

DAS GROSSE VEREINHEITLICHTE MODELL
 Umfasst die vollständige Domäne eines Unternehmens
 Ein schwer erreichbares Ideal
 Oft nicht lohnenswert anzuvisieren
Hoher Koordinationsaufwand in Teams
Führt oft zu einem big ball of mud

KONTEXTGRENZEN (BOUNDED CONTEXT)
 Jedes Modell hat einen Kontext
 Kontext = Grundsätzliche Voraussetzungen, damit Begriffe eine bestimmte
Bedeutung erhalten
 Wird ein Modell aufgespalten, so ist für jedes Teilmodell eine Kontextdefinition
erforderlich
 Setze explizite Grenzen in der…
 Organisation von Teams
 Benutzung von Teilen der
Applikation
 Codebasis
 Entwicklung von
Datenbank-Schemas

WIE SCHNEIDE ICH MEINE DOMÄNE?
 Nach Unterschieden in der Verwendung von Begriffen der Ubiquitous Language
 Nach Grenzen im Geschäftsprozess, die die Domänenexperten beschreiben
 Nach Abteilungen in der Organisation bzw. Gruppen von Domänenexperten
 NICHT: Nach Entities
oder Aggregaten!

BEISPIEL – BOUNDED CONTEXTE
NACH ABTEILUNG UND NACH PROZESS
VERTRIEB
Buchhaltung
HR

LIVING IN A BOX
 Erhalte die Konsistenz innerhalb der Grenzen
 Keine Ablenkung durch äußere Angelegenheiten
 Freie Gestaltung eines Teilmodells durch das zugehörige Team
 Kenne die Restriktionen
 Bleibe innerhalb der Modellgrenzen

JEDER BOUNDED CONTEXT HAT SEIN EIGENES
MODELL

 Subdomänen
 Kern (Core Domain)
 Unterstützende (Supporting Domain)
 Allgemeine (Generic Domain)
 Context Mapping
 Shared Kernel
 Customer/Supplier
 Open-Host-Service
 Published Language
 Separate Ways
 Anticorruption Layer
STRATEGISCHES DESIGN – WEITERE BEGRIFFE

DER PREIS FÜR DOMÄNENMODELLE
 Zusätzliche Arbeit
 Definition der Modellgrenzen
 Definition der Beziehungen zwischen verschiedenen Modellen (Context
Mapping)
 Abbildungen zwischen verschiedenen Modellen
 Objekte können nicht zwischen den BC transportiert werden

WAS WIR NICHT BAUEN WOLLEN
✘
ANEMIC DOMAIN MODEL
 „blutarme“ fachliche Objekte
 Schnittstelle ohne Aussagekraft
 aus Gettern/Settern
 Viele String Parameter
 Eigentliche Fachlichkeit außerhalb
Entities + Value Objects in Services
oder im UI
 Viele Util, Helper und Manager Klassen

ANEMIC  FEHLENDE ROBUSTHEIT
 Designschulden
 Unklarer, schwer verständlicher
Entwurf
 Verteilte Fachlichkeit
 Copy & Paste - Programmierung
 Teure Wartung
 Duplizierter Code
 Viele Refactorings
 Schlechte Testbarkeit

UNKLARE STRUKTUREN IN DER ACHITEKTUR

GROSSE ZYKLEN VERSCHMUTZEN DAS SYSTEM
463 classes from 10 different
domain-specific modules

119 Klassen aus 4 Komponenten
+ 28 weitere Klassen

Große Zyklen sichtbar machen
327 Klassen aus 8 Komponenten
brauchen sich gegenseitig

Dr. Carola Lilienthal
Geschäftsführerin
cl@wps.de
www.wps.de
+49 40 229 499-0
+49 40 229 499-299
+49 170 184 77 11
Diplom-Informatikerin
@cairolali
a @cairolali
cl@wps.de
www.llsa.de
Vielen Dank für Ihre Aufmerksamkeit!

Its all about the domain honey

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (8)

Andere mochten auch

Andere mochten auch (19)

Ähnlich wie Its all about the domain honey

Ähnlich wie Its all about the domain honey (20)

Mehr von Carola Lilienthal

Mehr von Carola Lilienthal (7)

Its all about the domain honey