Experten-Check Teil 2

Domain-driven Design im Experten-Check: Was sind die typischen Probleme bei der Umsetzung von DDD?

Hartmut Schlosser

(c) Shutterstock / Design Collection

Die Prinzipien für Domain-driven Design sind meist grundsätzlich bekannt – allein die Umsetzung in der Praxis ist alles andere als trivial. Im zweiten Teil unseres Experten-Checks gehen wir deshalb der Frage nach, auf welche typischen Probleme man bei der Umsetzung von DDD stößt. Außerdem: Wann sollte man von DDD lieber die Finger lassen?

Was sind die typischen Probleme bei der Umsetzung von DDD?

Carola Lilienthal: DDD steht und fällt mit einem guten Verständnis des Anwendungsgebiets. Sich dieses Verständnis anzueignen, fällt vielen Entwicklungsteams schwer. Einerseits haben die Anwender keine Zeit, ihr Wissen weiterzugeben und den Entwicklern bei einem systematischen Verständnis zu helfen. Andererseits bevorzugen viele Entwickler technische Fragestellungen vor der Vertiefung in fachliche Details. Hier muss ein echtes Umdenken stattfinden:

  • Die Entwickler müssen Freude daran entwickeln, Experten für ein Anwendungsgebiet zu sein.
  • Die Anwender müssen verstehen, dass die Software nur dann einen guten fachlichen Kern haben kann, wenn sie ihr Wissen umfänglich weitergeben und im gesamten Lebenszyklus des Systems zu Diskussionen bereit sind.

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: Entwickler denken meist eher technisch orientiert und haben es daher schwer, stärker als bisher auf die Fachlichkeit zu fokussieren. Hinzu kommt, dass viele Entwickler die Anwender beziehungweise Fachabteilungen schon so „erzogen“ haben, dass diese eine sehr technische Sprache und Denkweise angenommen haben. Da wird beispielsweise ganz selbstverständlich von Datenbanktabellen gesprochen – eigentlich ein reines Implementierungsdetail, das den Anwender nicht interessieren sollte. Hand in Hand damit geht ein starker CRUD-Fokus, den ich leider sehr oft erlebe. In einer domänengetriebenen Welt kann es das Editieren eines Datensatzes an sich nicht geben, stattdessen muss man sich überlegen, welche konkreten Geschäftsvorfälle eine „Änderung“ motivieren. Viele Fachabteilungen neigen dazu, in den Limitierungen vorhandener Systeme zu denken, anstelle einen Vorgang etwas abstrakter als Prozess zu sehen. Es ist daher oftmals schwierig, die richtigen Domänen-Experten zu finden, mit denen man DDD richtig umsetzen kann.

Lars Röwekamp: Das größte Problem ist fast immer das Finden einer gemeinsamen, fachlich motivierten Sprache zwischen Entwicklern und Fachexperten, in DDD „Ubiquitous Language“ genannt. Dies klingt zwar trivial, ist aber für den Erfolg eines Projektes essentiell. Denn erst, wenn ich mich auf diese eine gemeinsame Sprache (pro Fachdomäne) geeinigt habe, kann ich auch sicher sein, dass alle Beteiligten in den Diskussionen das Gleiche meinen. Gelingt dies nicht, sind Missverständnisse und somit fachliche Fehler in der Software bzw. dem Domänen-Modell per Definition vorprogrammiert.

Nehmen wir einmal das Beispiel „Arzt“. Aus Sicht eines Entwicklers ist ein Arzt ein Mensch, der andere Menschen in (s)einer Praxis behandelt und damit Geld verdient. Aus Sicht eines Fachexperten sind dies aber unter Umständen völlig verschiedene Dinge. Denn für den Fachexperten gibt es einen Behandler, einen Abrechner und einen Praxisbetreiber. Diese können ein und dieselbe Person sein, müssen es aber nicht. Unter Umständen sind es noch nicht einmal reale, sondern nur juristische Personen. Erst die Differenzierung in der Sprache und das damit verbundene Nutzen der Fachtermini stellt sicher, dass bei der Analyse der Fachlichkeit die Fachexperten und die Entwickler nicht aneinander vorbeireden. Dies wiederum ist die Grundvoraussetzung für korrekte Software.

Eberhard Wolff: Die Building Blocks wie Entity, Value Object, Repository usw. sind meistens bekannt – und auch intuitiv leicht zu erfassen. Aber Strategic Design und Bounded Context kennen viele nicht. Die Idee, dass selbst grundlegende Geschäftsobjekte wie Kunde oder Bestellung nicht allgemeingültig für ein ganzes Unternehmen definiert werden können, überrascht immer noch viele. Daher werden diese Patterns auch noch nicht breit genutzt. Gerade Strategic Design wirklich gut umzusetzen, erfordert also ein grundlegendes Umdenken.

Oliver Gierke: DDD ist ein weites Feld und betrifft sehr viele Aspekte des Softwareentwicklungsprozesses. Auf technischer Ebene sowohl im Bereich Makroarchitektur — welche Kontexte gibt es? Wie stehen diese zueinander in Beziehung? Wie werden diese abgebildet? usw. — als auch in einem Bereich irgendwo zwischen Mikroarchitektur und Design.

In letzterem Bereich, in dem vor allem die fundamentalen Bausteine wie Entitäten, Aggregate usw. in den Fokus geraten, gibt es nun erhebliche Berührungspunkte mit Frameworks aller Art. Hier ist es leider oft so, dass diese bestimmte Designvorgaben machen, die eine Umsetzung der DDD-Konzepte erschweren. Der Klassiker hierbei ist, dass JPA als ORM-Technologie, Default-Konstruktoren voraussetzt und sehr stark auf Mutabilität setzt, so dass es nur mit erheblichem Aufwand möglich ist, wirklich Businessregeln in Entitäten umzusetzen. Java als Sprache erfordert sehr viel Aufwand für die Implementierung von Value Objects. Hinzu kommt, dass es viel Technologie gibt, die einfach schlicht falsche Anreize setzt und vorlebt, @Email String email wäre ein adäquater Ersatz für einen dezidierten Typ EmailAddress.

Mein Punkt ist, dass man als Entwickler auf der Umsetzungsebene oft mit erheblichem Mehraufwand Unzulänglichkeiten von Technologie ausgleichen muss, was oft dazu führt, dass man Konzepte und Ideen aus DDD nur halb umsetzt und damit einen großen Teil des Mehrwertes verschenkt.

Henning Schwentner: Wir Entwickler haben immer Lust auf die neuesten Trends, Frameworks, Programmiersprachen usw. Wir wollen gerne all dieses Neue ausprobieren und in unsere Projekte einbauen. Das ist gut und richig, aber wir dürfen nicht der Versuchung erliegen, uns nur technik- und selbstverliebt um die neuesten Technologien zu drehen. Wir müssen ein gutes und belastbares Fachmodell bauen, denn nur so können wir unseren Anwender bei ihrer Arbeit unterstützen. Und das ist unsere Hauptaufgabe; alles andere ist sekundär.

Oft wird technischer und fachlicher Code gemischt. Das führt zu Problemen, weil Fachlichkeit und Technik sich in unterschiedlichen Zyklen ändern. Wir wollen unseren fachlichen Code stabil halten und nicht ändern müssen, weil es z.B. eine neue Oberflächentechnologie gibt.

Jimmy Nilsson: Ein sehr typisches Problem ist, dass DDD in realen Projekten nur als ein Technologie-Stil eingesetzt wird. So hilft es nicht wirklich viel, ist zugleich für die Entwickler aber anspruchsvoll in der Umsetzung. Im Ergebnis erzielt man eine niedrige Produktivität ohne wirklichen Mehrwert.

Michael Plöd: Ich sehe im Praxiseinsatz primär zwei Umsetzungsprobleme. Erstens verstehen viele Teams die grundsätzlichen Building Blocks wie Value Objects, Repositories oder Entities, aber ich stelle immer wieder fest, dass das Value Object viel zu selten zum Einsatz kommt und dass gerade Aggregate im Laufe von Projekten einer „Architektur-Korrosion“ zum Opfer fallen. Des Weiteren werden die Werkzeuge des Context Mappings aus Strategic Design gerade bei Transformationsplanungen vernachlässigt. Gerade eine Skizzierung einer bestehenden Landschaft, die über einfache Liefer- und Leistungsbeziehungen hinausgeht, findet häufig nicht oder nur unzureichend statt, was schade ist, weil die Klassifizierung mit Hilfe der Context Mapping Patterns viele wertvolle Informationen liefert.

 

 

Lesen Sie auch: Domain-driven Design im Experten-Check – Teil 1: Warum ist DDD heute relevanter denn je?

 

Bildschirmfoto 2016-08-31 um 11.01.35

 

Von DDD sollte man die Finger lassen, wenn…

… man lediglich Anwendungen zur reinen Verwaltung von Entitäten (a.k.a. CRUD-Anwendung), wie z.B. administrative Oberflächen, baut. Lars Röwekamp

… man kein Interesse an Diskussionen über die Fachlichkeit hat und am liebsten Technologien ausprobiert. Carola Lilienthal

… man nur an kurzfristigem Erfolg interessiert ist und beispielsweise Projektfortschritt anhand von erstellten Listenansichten und Masken zur Änderung von Datensätzen messen möchte. Stefan Priebsch

…das Projekt eine niedrige fachliche Komplexität hat.  Eberhard Wolff

… man sich nicht mit der Fachlichkeit beschäftigen möchte. Und dann sollte man eigentlich von der Softwareentwicklung im Ganzen die Finger lassen. Henning Schwentner

… nicht das ganze Projektteam mitspielt oder wenn man einfach CRUD-Anwendungen entwickelt. Michael Plöd

 

Lesen Sie in Teil 3 unseres Experten-Checks: Wie kann DDD in die Praxis umgesetzt werden?

 

 

W-JAX
Mike Wiesner

Data- und Event-driven Microservices mit Apache Kafka

mit Mike Wiesner (MHP – A Porsche Company)

Niko Köbler

Digitization Solutions – a new Breed of Software

with Uwe Friedrichsen (codecentric AG)

Software Architecture Summit 2017
Dr. Carola Lilienthal

The Core of Domain-Driven Design

mit Dr. Carola Lilienthal (Workplace Solutions)

Sascha Möllering

Reaktive Architekturen mit Microservices

mit Sascha Möllering (Amazon Web Services Germany)

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.