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, [email protected], @cairolaliwww.wps.de

03.05.2023 //// Seite 3WPS - Workplace Solutions GmbH

Software-Architektur

Anforderungs-ermittlung

Leitstand und Interaktion

Individual-software

Business-Software,die Spaß macht!

WPS – Workplace Solutions GmbH

Foto

: J. R

ost


Dr. Carola LilienthalGeschäftsführerin

[email protected]

+49 40 229 499-0+49 40 229 499-299+49 170 184 77 11

Diplom-Informatikerin

@cairolali

a

@[email protected]

Schulung Domain-Driven DesignModul für Advanced Level

wps.de/ddd


WIR SIND PROGRAMMIERER...


... UND WIR LIEBEN TECHNIK


SOFTWARE != SELBSTZWECK

Software ist ein Mittel zum ZweckKein SelbstzweckDas 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-MappingInheritan

ce

A

B

Method

Interface

LinuxWindow

s

EclipseVisual Studio


DOMÄNEN-SPRACHE

Container

Containernummer

4300

Kran

Twistlock

Konnossement

Beispiel: Hafen


Fach-sprach

eTechno Babble

?

UBIQUITOUS LANGUAGE


Fach-sprach

eTechno Babble

Fach-sprach

e

UBIQUITOUS LANGUAGE


Fach-sprach

eTechno Babble

UBIQUITOUS LANGUAGE


Techno Babble

Fach-sprach

e

UBIQUITOUS LANGUAGE


Fach-sprach

e

{Techno Babble}

?

UBIQUITOUS LANGUAGE


Fach-sprach

e

{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

SpielerNichtmenschlich

er 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 nichtversteht, kann ihr nicht helfen

Softwareentwickler undFachexperten 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 EventsCommandsActeureAggregate


DOMAIN STORYTELLING

www.domainstorytelling.org

Modelliert werden:AkteureGegenständeHandlungen


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 TeamsFü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 CONTEXTENACH ABTEILUNG UND NACH PROZESS

VERTRIEB

Buchhaltung

HRLohnbuchhaltungRecruiting

Vertrieb


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

Bewegung

Kosmetik


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 LilienthalGeschäftsführerin

[email protected]

+49 40 229 499-0+49 40 229 499-299+49 170 184 77 11

Diplom-Informatikerin

@cairolali

a

@[email protected]

Vielen Dank für Ihre Aufmerksamkeit!