Softwareentwicklung ist Modell-Bildung. Wir bauen einen Teil der Wirklichkeit als Programm nach und verbessern sie so. Ein traditioneller Ansatz ist, die Domäne als Ganzes möglichst detailgenau nachzubilden. Aber ist das eigentlich der Zweck von Modellen? Wenn wir genau hinschauen, bemerken wir, dass ein Modell eigentlich genau das Gegenteil ist. Ein Modell ist nämlich eine Abstraktion der Wirklichkeit, in die nur das Wesentliche übertragen und das Unwesentliche weggelassen wird. Was wesentlich und was unwesentlich ist, ergibt sich aus dem Kontext. Ein einfaches Modell ist leichter zu verstehen als ein kompliziertes. Deshalb ist es eine gute Idee, von einer komplizierten Wirklichkeit mehrere einfache (und einfach verständliche) Modelle zu bilden. Genau diesen Effekt machen sich Microservices und DDD mit seinem Strategisches Design zu nutze. Hier werden statt dem einen großen unternehmensweiten Modell, mehrere kleine gut verständliche Modelle gebildet. In diesem Talk betrachten wir, welche Mittel uns zur Verfügung stehen, um gute Modelle zu bauen und die Domäne so aufzuteilen, dass wir auch mit mehreren sinnvoll und unabhängig arbeiten können.

1. WPS - Workplace Solutions GmbH //// Hans-Henny-Jahnn-Weg 29 //// 22085 HAMBURG
The joy of multiple models
Wie man einen Monolithen mit DDD aufschneidet
Dr. Carola Lilienthal, cl@wps.de, @cairolali
www.wps.de

2. @cairolali
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
@cairolali
cl@wps.de
www.llsa.de

3. @cairolali
Software-
Architektur
Domain
Storytelling
Arbeitsplatz
der Zukunft
Individual-
software
Business-Software,
die Spaß macht!
WPS – Workplace Solutions GmbH

5. 463 tangled classes belonging to
10 different components

6. @cairolali

8. Team Head
Team Tail
Team Body
Team Leg

9. Team Head
Team Tail
Team Body
Team Leg

10. Team Head
Team Tail
Team Body
Team Leg

11. Team Head
Team Tail
Team Body
Team Leg

12. Team Emma
Team Berta
Team Erna
Team Lisl

13. @cairolali
DIE DOMÄNE IN DER SOFTWARE IST EIN MODELL
▪ Eine interne Repräsentation der betrachteten Domäne
▪ Ausgehend von der Domäne werden die Kernelemente:
▪ Organisiere
▪ Systematisiere
▪ Zerlege in Bestandteile
▪ Gruppiere diese Bestandteile in Module

14. @cairolali
JEDER BOUNDED CONTEXT HAT SEIN EIGENES MODELL
ZIEL:
▪ Jedes Team kann an seinem eigenen Domänen-Modell arbeiten
▪ Man kennt seine Grenzen
▪ Man bleibt in seinen Grenzen

15. @cairolali
DAS GROSSE VEREINHEITLICHTE MODELL
▪ Umfasst die vollständige Domäne eines Unternehmens
▪ Ein nicht erreichbares Ideal
▪ Oft nicht lohnenswert anzuvisieren
➔Hoher Koordinationsaufwand in Teams
➔Führt oft zu einem big ball of mud

18. @cairolali
WIE SCHNEIDE ICH MEINE DOMÄNE?
▪ Nach Abteilungen in der Organisation bzw. Gruppen von Domänenexperten
▪ Nach Unterschieden in der Verwendung/Definition von Schlüsselkonzepten in der Domäne
▪ Nach Grenzen im Geschäftsprozess, die die Domänenexperten beschreiben
▪ Information läuft in eine Richtung
▪ Prozesse werden in unterschiedlichen
Rhythmen ausgeführt
▪ Prozesse werden von verschiedenen
Triggern ausgelöst.

19. @cairolali

20. @cairolali
Trigger
Trigger

21. @cairolali
Einmal pro Woche
Trigger
Trigger

22. @cairolali
Einmal pro Woche
Trigger
Trigger
Immer wenn ein
Kunde kommt

23. @cairolali
Einmal pro Woche
Trigger
Informationsfluss
Trigger
Immer wenn ein
Kunde kommt

24. @cairolali
Einmal pro Woche
Informationsfluss
Trigger
Immer wenn ein
Kunde kommt
Abteilung
Kinomanagement
Abteilung
Kartenverkauf
Trigger

25. @cairolali
Einmal pro Woche
Informationsfluss
Trigger
Trigger
Immer wenn ein
Kunde kommt
Abteilung
Kinomanagement
Abteilung
Kartenverkauf

26. @cairolali
LIVING IN A BOX – BOUNDED CONTEXT
→ Jedes Modell bekommt 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

27. @cairolali
Fach-
sprache
Techno
Babble
?
UBIQUITOUS LANGUAGE

28. @cairolali
Fach-
sprache
Techno
Babble
Fach-
sprache
UBIQUITOUS LANGUAGE

29. @cairolali
Fach-
sprache
Techno
Babble
UBIQUITOUS LANGUAGE

30. @cairolali
Techno
Babble
Fach-
sprache
UBIQUITOUS LANGUAGE

31. @cairolali
Fach-
sprache
{
Techno
Babble
}
?
UBIQUITOUS LANGUAGE

32. @cairolali
Fach-
sprache
{
Fach-
sprache
}
UBIQUITOUS LANGUAGE

33. @cairolali
TAKTISCHES UND STRATEGISCHES MODELLIEREN
Strategisches Modellieren (im Großen)
▪ Teile die Domäne in getrennte Bounded Contexts auf
▪ Jeder BC hat seine eigene ubiquitous language und sein eigenes Domänenmodell
Taktisches Modellieren (im Kleinen)
▪ Innerhalb eines Bounded Context
▪ Ubiquitous Language als Grundlage
▪ Building Blocks: Entity, Value Object,
Aggregate, Service, Repository, Factory

34. @cairolali
BUILDING BLOCKS = MUSTER FÜR DIE MIKRO ARCHITEKTUR
User Interface
Domain
Application
SchichtungdurchMuster
Bounded Context
Repository
Factory
Model
View
ValueObject
Service
Entity/
Aggregate
Controller

35. @cairolali

36. @cairolali
BUILDING BLOCKS
Wurzel-Entity
Entity
Entity
Entity
Entity
VO
VO VO
VO
VO VO VO VO
VO
VO
VO
VO
Aggregate
Service

37. @cairolali
MAKRO ARCHITEKTUR FAST OHNE VERLETZUNGEN

38. @cairolali
Problem A
Problem B
CHAOS IN DER MIKRO ARCHITEKTUR
◼ 98% aller Klassen kennen 10 andere Klassen
◼ „Problem A“ braucht 21 Klassen und wird von 49 Klassen verwendet
◼ „Problem B“ braucht 63 Klassen und wird von 18 Klassen verwendet
◼ 30% aller Klassen in Zyklen
◼ 60% aller Packages in Zyklen

39. @cairolali
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

40. @cairolali
ANEMIC → FEHLENDE ROBUSTHEIT
▪ Designschulden
▪ Unklarer, schwer verständlicher Entwurf
▪ Verteilte Fachlichkeit
▪ Copy & Paste - Programmierung
→ Teure Wartung
→ Duplizierter Code
→ Viele Refactorings
→ Schlechte Testbarkeit

41. @cairolali
GROSSE ZYKLEN VERSCHMUTZEN DAS SYSTEM
119 Klassen aus 4 Komponenten
+ 28 weitere Klassen

42. @cairolali
GROSSE ZYKLEN VERSCHMUTZEN DAS SYSTEM
327 Klassen aus 8 Komponenten
brauchen sich gegenseitig

43. @cairolali
MODULARITY MATURITY INDEX (MMI)
612.869 LOC
14.756.435 LOC
252.062 LOC
804.093 LOC
543.388 LOC
1.035.668 LOC
486.358 LOC
175.258 LOC
42.311 LOC
193.383 LOC
643.466 LOC
245.754 LOC
2.890.204 LOC
141.696 LOC
512.086 LOC
9.988.363 LOC
200.591 LOC
922.949 LOC
22.658 LOC
663.862 LOC
3.270.188 LOC
1.521.357 LOC
0
2
4
6
8
10

44. @cairolali
MEETUPS
@DDDger

45. @cairolali
KONFERENZEN
Germanys first DDD conference

46. Schulungen zu Architektur und Domain-Driven Design
Architekturanalyse mit IhremTeam
wps.de

47. @cairolali
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
@cairolali
cl@wps.de
www.llsa.de
Vielen Dank für Ihre Aufmerksamkeit!