Suche
Experten-Check Teil 3

Domain-driven Design im Experten-Check: Wie kann DDD in die Praxis umgesetzt werden?

Hartmut Schlosser

(c) Shutterstock / Design Collection

Acht Experten für Domain-driven Design geben Einblicke in ihre Praxiserfahrungen mit DDD. Im dritten Teil haben wir die Experten gebeten, uns einen Tipp zu geben, wie man DDD in realen Projekten erfolgreich einsetzen kann. Außerdem: Weshalb profitieren Microservice-Architekturen von DDD?

Wie kann DDD in die Praxis umgesetzt werden?

Carola Lilienthal: Anwender und Entwickler müssen sich zu Beginn der Entwickler sehr oft treffen und über die Fachlichkeit diskutieren. Dabei sollten die Entwickler Schritt für Schritt ein immer feinere Modell der Fachsprache entwerfen, das sie mit den Anwender dann hinterfragen. Hat man hier einen ersten guten Stand erreicht, kann mit der Implementierung begonnen werden. Wichtig ist dabei, dass auch tatsächliche die Begriffe der Anwendungswelt verwendet werden.

Die DDD-Experten

Stefan Priebsch_1_0

Stefan Priebsch, Co-Founder der The PHP Consulting Company.

gierke_oliver_0

Oliver Gierke, Leiter des Spring-Data-Projekts bei Pivotal.

Henning Schwentner_wp

Henning Schwentner, Softwarearchitekt und Berater bei der WPS.

Carola Lilienthal_5

Dr. Carola Lilienthal, Seniorsoftwarearchitektin bei der Workplace Solutions GmbH.

ich-small-2679

Michael Plöd, Principal Consultant bei innoQ.

Wolff_eberhard_wp

Eberhard Wolff, Architekt, Berater und Fellow bei innoQ.

Lars Röwekamp

Gründer des IT-Beratungs- und Entwicklungs- unternehmens open knowledge GmbH

Jimmy_Nilsson

CEO von factor10 und Autor des Buches „Applying Domain-Driven Design and Patterns“

Stefan Priebsch: Vergesst erst einmal alles, was Ihr jemals über Technik und Software-Entwicklung gelernt habt. Setzt euch stattdessen mit der Fachabteilung (den „Domänen-Experten“) zusammen, verteilt die Rollen und spielt den Ablauf, den ihr gerade betrachtet, als eine Art Pen-and-Paper-Rollenspiel durch. Versucht nicht, alle Probleme auf einmal zu lösen, sondern nehmt euch einen häufig auftretenden Fall vor. Dann geht daran, das Pen-and-Paper-Rollenspiel in Software umzusetzen und ersetzt damit einen Teil der vorhandenen Legacy-Software.

Lars Röwekamp: Mein Pro-Tipp No. 1 heißt „üben, üben, üben.“ Das klingt trivial, ist aber nach unseren Erfahrungen der Schlüssel zum Erfolg. Wichtig dabei ist, dass sich Fachexperten und Entwickler immer wieder an einen Tisch setzen und über die umzusetzende Fachlichkeit und das aktuelle Domänen-Modell diskutieren. Dabei wird es immer wieder zu neuen Erkenntnissen und damit einhergehend zu einem beidseitig besseren Verständnis der fachlichen Domäne kommen. Natürlich können diese Erkenntnisse dazu führen, dass Änderungen am bestehenden Code notwendig sind. Aber das ist auch gut so. Denn um ehrlich zu sein, wäre es ja schon verwunderlich, wenn sich die Sicht auf die Fachlichkeit ändert, der zugehörige Code aber unverändert bleibt, denn dann hätte ich bereits vorher etwas falsch gemacht.

Eberhard Wolff: Bei meinen Trainings setze ich darauf, konkrete Beispiele nach DDD praktisch entwerfen zu lassen. Dabei fokussiere ich jeweils auf eine Ebene von DDD – beispielsweise Building Blocks oder Strategic Design. Die Ergebnisse diskutieren wir dann, und ich gebe ebenfalls Feedback – das erleichtert den Start.

Oliver Gierke: Hier würde ich vermutlich analog zur Aufteilung des Buches zwei große Bereiche unterscheiden: den makro-architektonischen in Bezug auf die Kontextaufteilung und den eher mikro-architektonischen in Bezug auf die Umsetzung und die verwendeten Technologien.

In ersterem plädiere ich üblicherweise dazu, nicht mit Überaufteilung zu beginnen. Zum einen gibt es bei wenig Erfahrung mit großen Systemlandschaften vielerlei neue Herausforderung wie z.B. das Monitoring dieser Landschaft, die erst einmal gelöst werden wollen. Hier ist man dann oft mit eher technischen Aspekten beschäftigt — etwas, was Entwicklern üblicherweise großen Spaß bereitet, wobei man dann darauf achten muss, sich nicht darin zu verlieren. Sonst baut man schlussendlich eher Framework als Fachlichkeit.

Der eigentlich viel zentralere Punkt ist meiner Meinung nach jedoch der Fakt, dass gerade im frühen Stadium eines Projektes noch vergleichsweise wenig Wissen über die Domäne besteht. D.h. man lernt zu diesem Zeitpunkt besonders viel über sie, und es ergibt sich üblicherweise regelmäßiger, recht umfangreicher Änderungsbedarf. In einem eher monolithischen System sind Änderungen einfacher zu realisieren als in einem sehr stark verteilten. In diesem Zusammenhang kann es also durchaus von Vorteil sein, zwei oder drei Kontexte, über deren Grenzen und Ausgestaltung man sich noch nicht ganz im Klaren ist, in einem System zu halten, bis man eine gewisse Reife erreicht. Wenn dieses System dann sauber strukturiert ist, lässt es sich auch in einem späteren Schritt noch gut separieren, sollte es notwendig werden, das zu tun.

Auf der anderen Seite ist es jedoch auch schwierig, mit nur einem System zu starten. Vor allem, da man damit die Kosten, die eine Aufteilung später mit sich bringt, auf einen späteren Projektzeitpunkt verschiebt. Einem Zeitpunkt, an dem man sich eigentlich nicht mehr grundsätzlich überlegen will, wie Systeme jetzt plötzlich miteinander kommunizieren sollen, wie man die Systemlandschaft überwacht, usw.

Henning Schwentner: In der Praxis enstehen leider zu häufig blutleere Fachmodelle. Da wird dann schon ein Datensack (d.h. eine Klasse, die nur Getter und Setter hat) als Entity bezeichnet. Was wir aber eigentlich wollen, sind reichhaltige Fachmodelle. Und die bestehen aus Klassen mit fachlichen Operationen. Wie erhalte ich solche fachlichen Operationen? Dazu empfiehlt es sich, sich den Umgang der Entity in der Wirklichkeit anzuschauen. Oft ist es eine gute Idee, aus jeder Umgangsform der echten Entity eine Methode an der Entity-Klasse zu machen. So entsteht ein Modell und eine Software, die die Realität abbilden. (Demjenigen, der sich tiefer dafür interessiert empfehle ich, sich den Werkzeug&Material-Ansatz näher anzuschauen, z.B. unter www.wam-ansatz.de).

Jimmy Nilsson: Ich schlage vor, sich auf den Aspekt der Zusammenarbeit zu konzentrieren, anstatt verschiedene Modelle zur Problemlösung zu untersuchen. Spiele mit diesen Modellen, probiere sie aus. Und stelle dich darauf ein, dass sie sich ändern werden. Höre nie auf, die Modelle während der Anwendung zu verbessern.

Michael Plöd: Ich finde es gut, gerade Anfangs bei den Building Blocks oder bei Strategic Design strikt nach Lehrbuch zu arbeiten und keine Ausnahmen, beispielsweise beim Entwurf von Value Objects oder Aggregaten zuzulassen. Weiterhin finde ich kleine Modellierungsworkshops, in denen die Projektteilnehmer DDD-Praktiken üben, wertvoll. Der Begriff „Projektteilnehmer“ inkludiert hier zudem ganz klar auch fachliche Teammitglieder, denn ohne Verständnis von DDD beim Fachbereich wird sich das Entwicklungsteam schwer tun, DDD erfolgreich zu etablieren.

Lesen Sie auch:

DDD-Experten-Check – Teil 1: Warum ist DDD heute relevanter denn je?

DDD-Experten-Check – Teil 2: Was sind die typischen Probleme bei der Umsetzung von DDD?

 

Bildschirmfoto 2016-08-31 um 11.01.35

 

Microservice-Architekturen profitieren von DDD-Konzepten, weil …

 

…das Konzept Bounded Context hilft, einzelne Microservices abzugrenzen. Carola Lilienthal

… der Bounded Context aus DDD eine natürliche Grenze für einen Microservice bildet und so die größtmögliche Unabhängigkeit eines Services zu seinen Nachbarn garantiert. Lars Röwekamp

… weil beide Ansätze die Idee von starken Grenzen (Boundaries) teilen und DDD einem Werkzeuge an die Hand gibt, innerhalb solcher Grenzen Software zu entwerfen, die in sich abgeschlossen funktioniert. Stefan Priebsch

…  Strategic Design und Bounded Context die fachliche Aufteilung eines Systems in Microservices erleichtern. Eberhard Wolff

… sie ohne das Strategic Design von DDD nicht denkbar sind. Henning Schwentner

… DDD gerade im Umfeld von Strategic Design wertvolle Hilfsmittel zur Modellierung von Microservices liefert (Bounded Context, Context Map) und weil DDD durch die Building Blocks bewährte Patterns zum Implementierung einzelner Microservices bereit hält. Michael Plöd

Verwandte Themen:

Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Hartmut Schlosser ist Redakteur und Online-Koordinator bei Software & Support Media. Seine Spezialgebiete liegen bei Java-Enterprise-Technologien, JavaFX, Eclipse und DevOps. Vor seiner Tätigkeit bei S & S Media studierte er Musik, Informatik, französische Philologie und Ethnologie.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.