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: 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?

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?

In unserem Themen-Dossier zu Domain-driven Design dreht sich alles um die Frage, wie man Konzepte des DDD in die Praxis umsetzt.
Bisher erschienen:

• Einführung in die Konzepte von Domain-driven Design
• Eric Evans: DDD & Microservices – die JAX-Keynote
• DDD & REST – Domain Driven APIs für das Web
• “Microservices können Teams dabei helfen, DDD zu praktizieren” [Interview mit Eric Evans]
• Domain-driven Design: Ketchup oder Mayo?
• Domain-driven Design im Experten-Check – Teil 1: Warum ist DDD heute relevanter denn je?
• DDD versus DSLs: Was Domain-driven Design mit domänenspezifischen Sprachen zu tun hat
• Domain-driven Design im Experten-Check – Teil 2: Was sind die typischen Probleme bei der Umsetzung von DDD?