Its all about the domain honey

WPS - Workplace Solutions GmbH //// Hans-Henny-Jahnn-Weg 29 //// 22085 HAMBURG
It’s all about the domain, honey!
Dr. Carola Lilienthal
Carola.Lilienthal@wps.de, @cairolali
www.wps.de

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

WIR SIND PROGRAMMIERER...

... UND WIR LIEBEN TECHNIK

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

ANWENDER

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

WAS IST DIE DOMÄNE?
 Domäne: Ein abgrenzbares Problemfeld, dem eine Software gewidmet ist
 Software entspringt einer Domäne und steht damit in engem Zusammenhang
 Es ist verlockend, zu viel Zeit mit dem technischen Code zu verbringen!

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

DAS MODELL KOMMUNIZIEREN
 Das Modell kann nicht nur in unseren Köpfen bestehen
 Wir müssen Wissen und Informationen verteilen
 Grafisch
 Schriftlich
 Mündlich
Eine gemeinsame Sprache ist notwendig, um
das Modell ausdrücken zu können

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
?
ALLGEGENWÄRTIGE FACHSPRACHE

Fach-
sprache
Techno
Babble
Fach-
sprache

Fach-
sprache
Techno
Babble

Techno
Babble
Fach-
sprache

Fach-
sprache
{
Techno
Babble
}
?

Fach-
sprache
{
Fach-
sprache
}

 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

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

WORKSHOPS ZU PROZESSA- UND ANFORDERUNGS-
ANALYSE MIT ANWENDERN ODER DEM PO
“Georgia?” by The Library of Congress, flickr.com
• Teilnehmer aus verschiedenen Bereichen (Business, IT, Management, …)
• 1 Moderator, 1 Modellierer an der Tastatur
• “live” Modellierung mit einem Projektor
 direktes Feedback von allen Beteiligten

eGPM „Die Methode mit den Männchen“
http://www.omilab.org/web/bpm
Wer tut was
womit und
warum?

Glossar
• Fachsprache der Benutzer
• bereits existierende Begriffe
• rekonstruierte Begriffe
• neue Begriffsbildungen
• Wer tut was damit warum?

DIE OBJEKTORIENTIERTE GRUNDIDEE:
FACHLICHE GEGENSTÄNDE ALS AUSGANGSPUNKT

DIE OBJEKTORIENTIERTE GRUNDIDEE: AUS
FACHLICHEN
GEGENSTÄNDEN WERDEN KLASSEN
Die Artefakte
der Fachdomäne...
... werden in ihrem Verhalten
fachlich modelliert ...
einfügen
beschriften
suchen
entnehmen
Der Kundenordner
... und softwaretechnisch in fachlichen Klassen beschrieben.
beschriften
suchen
Liste der
Dokumente
Zeichenkette
Integer
Klasse Ordner
einfügen (Dokument doc)
{
assert doc!=null, „NN“);
…
docs.add(doc);
}
entnehmen
einfügen

SCHNITTSTELLEN DER FACHLICHEN KLASSEN
Das Konzept der Modellierung von fachlichen Klassen:
• Wähle anwendungsfachliche Begriffe ( als Substantiv)
• Beschreibe Umgangsformen ( als Verb) und die dabei benötigten
weiteren Gegenstände.
Keine Daten
modellieren.
Ordner
- Dokument entnehmen
- Dokument einfügen
- mit Text beschriften
- Beschriftung?
- Dokument suchen
- Dokument auswählen
- das Register aufschlagen
- voll?
...

TRENNUNG VON FACHLICHER + TECHNISCHER SOFTWARE
Application Kernel
Persistence
GUI 2
Database
Altsystem B
Altsystem A
Adapter
A
Adapter
B
GUI 1
interfaces submitted to
third parties
Transformations-Software
Technische Software
Vermischte Software
Fachliche Software

ELEMENTE VON DOMAIN-DRIVEN-DESIGN
Services
Factories
Value Objects
Repositories
Aggregates
Entities
Infrastruktur-
Komponente
"Mikro-Schichtung"
Fachobjekte
Unterstützen den
Lebenszyklus der
Fachobjekte

DIE FACHLICHEN „KERNELEMENTE“ VON DDD
Services
Value Objects
Entities
zustandslos
veränderlicher
Zustand
unveränderlicher
Zustand
"Mikro-Schichtung"

ENTITIES
 Sind die Kernobjekte einer
Fachdomäne.
 Besitzen eine
zustandsunabhängige,
unveränderliche Identität.
 Haben einen klar definierten
Lebenszyklus.
 Besitzen einen (meist
veränderlichen) Zustand.
 Beschreiben ihren Zustand
mithilfe von ValueObjects.
 Sind praktisch immer
persistent.
Versicherungs-
nehmer
• Name
• Vorname
• Straße
• PLZ
• Ort
• Versicherungs-
nummer
Beitrags-
zahler
• Name
• Vorname
• IBAN
• BIC
Versicherte
Person
• Name
• Vorname
• Tarif
Forderung
• Geldbetrag
• Fälligkeit
• Schuldner
Bankver-
bindung
• IBAN
• BIC
Person
• Name
• Vorname
✘
✔

ENTITIES – BEISPIELE
Versicherungspolice
Urlaubsantrag
Baumaßnahme
Kaufvertrag
Fahrauftrag

VALUE OBJECTS
 Symbolisieren Werte
eines bestimmtenTyps
der Fachdomäne.
 Symbolisieren bei
Gleichheit denselben
Wert.
 Sind unveränderlich.
 Können ggf. (aus
anderen ValueObjects)
berechnet werden.
 Können aus anderen
ValueObjects bestehen,
aber nie aus Entitäten!
ValueObject
2,5
ValueObject
ValueObject
ValueObject
ValueObject
zwei-
einhalb

VALUE OBJECTS – BEISPIELE
Postleitzahl
GPS-Koordinate
IBAN
Containernummer
IATA-Code

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
 Oberhalb des Modells findet man Klassen
mit dupliziertem Code zur
 Konsistenzprüfung
 Konvertierung
 Validierung
 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
119 Klassen aus 4 Komponenten
+ 28 weitere Klassen

GROSSE ZYKLEN VERSCHMUTZEN DAS SYSTEM
327 Klassen aus 8
Komponenten
brauchen sich gegenseitig

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

KEIN GROSSES VEREINHEITLICHTES MODELL
 Die vollständige Domäne ist zu groß für ein einzelnes Modell
 Bewusste Aufspaltung in Teilmodelle
 Separate Modelle
 können unabhängig entwickelt werden
 Müssen den an sie gestellten
Anforderungen genügen
 sollten klar abgegrenzt sein
 Jedes Modell sollte klein genug sein, so
dass man es einem Team zuweisen kann

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

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
 Häufig werden Wertobjekte für die
Kontext-Interkommunikation verwendet

KONTEXTÜBERSICHT (CONTEXT MAP)
 Jedes Team kennt seinen Kontextgrenzen. Wie steht es um die anderen?
 Eine Kontextübersicht skizziert
 Die verschiedenen abgegrenzten Kontexte
 ihre wechselseitigen Beziehungen
 Abgegrenzte Kontexte sollten
benannt sein.

SHARED KERNEL
 Teams verwenden mitunter ähnliche Modelle.
 Um Duplizierung zu vermeiden, einigen sich diese Teams auf ein gemeinsam
genutztes Teilmodell, den Shared Kernel.
 Wird dieser Shared Kernel weiterentwickelt, werden alle beteiligten Teams mit
einbezogen.
 Die Kontexte der Teams bleiben weiterhin voneinander abgegrenzt.
Address
Bank Data

MICROSERVICES AND SELF-CONTAINED SYSTEMS
Micro-
service A
UI
Entities
Value
Objects
Services
Micro-
service B
UI
Entities
Value
Objects
Services
Micro-
service C
UI
Entities
Value
Objects
Services
TechnischeSchichtung
Value
Object
Value
Object
? ?

MOB-ARCHITEKTUR-REFACTORING

Vielen Dank für Ihre Aufmerksamkeit!
www.langlebige-softwarearchitektur.de
Dr. Carola Lilienthal
Mitglied der
Geschäftsleitung
cl@wps.de
www.wps.de
+49 170 184 77 11
Diplom-Informatikerin
@cairolali

Its all about the domain honey

Recommended

Recommended

More Related Content

What's hot

What's hot (12)

Viewers also liked

Viewers also liked (11)

Similar to Its all about the domain honey

Similar to Its all about the domain honey (20)

More from Carola Lilienthal

More from Carola Lilienthal (6)

Its all about the domain honey