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

[email protected], @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-MappingInheritance

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

NichtmenschlicherSpieler


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 Verhaltenfachlich 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 AAdapter

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"M

ikro

-Schic

htu

ng"

Fachobjekte

Unterstützen den

Lebenszyklus der

Fachobjekte


DIE FACHLICHEN „KERNELEMENTE“ VON DDD

Services

Value Objects

Entities

zustandslos

veränderlicher

Zustand

unveränderlicher

Zustand

"Mik

ro-S

chic

htu

ng"


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 bestimmten Typs

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

Tech

nis

che

Sch

ich

tun

g

Value

ObjectValue

Object

? ?


MOB-ARCHITEKTUR-REFACTORING

Vielen Dank für Ihre Aufmerksamkeit!

www.langlebige-softwarearchitektur.de

Dr. Carola LilienthalMitglied der

Geschäftsleitung

[email protected]

www.wps.de

+49 170 184 77 11

Diplom-Informatikerin

@cairolali