© love_is_love/Shutterstock.com
Eine kompakte Einführung in Domain-driven Design

Dieselbe Sprache sprechen


Die Zusammenarbeit zwischen IT- und Fachabteilung ist bei Softwareprojekten seit jeher ein Problem: Egal, ob bei Softwareprojekten oder in Warenwirtschaftssystemen, es gilt, dass der Entwickler nicht das komplette Bild der Applikationsdomäne im Kopf haben kann. Der 2003 erstmals vorgestellte Ansatz des Domain-driven Design möchte Abhilfe schaffen.

Die erstmalige Vorstellung des Konzepts des Domain-driven Design (DDD) erfolgte, als Eric Evans im Jahr 2003 sein Buch „Domain-driven Design“ auf den Markt brachte. Das Werk war mit rund 400 Seiten nicht besonders lang, im Vergleich zu vorangegangenen Design-Pattern-Werken ob seiner Form aber alles andere als einfach zu lesen. An strukturierte Prozesse gewöhnte Entwickler reagierten darauf oft wie Marcos Vinícius Silva, der im Jahr 2019 folgende, wenig schmeichelhafte Feststellung tätigte: „Most likely nobody but Evans understands DDD, due to its complexity, so I wouldn’t recommend it to simple apps.“ Dennoch gibt es in DDD sehr wertvolle Aspekte, die wir in diesem Artikel kurz beleuchten wollen. Quasi nebenbei stellen wir einige Schlagwörter vor, die bei der Arbeit mit von DDD abgeleiteten Prozessen immer wieder fallen.

Gemeinsame Sprache (Ubiquitous Language)

Im DDD-Einführungswerk beginnt der Autor seine Erzählungen mit der Besprechung seiner Abenteuer im Bereich der EDA-Software: Dabei handelt es sich, wie beispielsweise in Abbildung 1 gezeigt, um Software, die die Erzeugung von Platinen am Rechner erledigt.

hanna_ddd_1.tif_fmt1.jpgAbb. 1: EDA-Systeme, wie hier Target 3001, helfen bei der Generierung von Platinenlayouts

Als primäres Problem stellte Eric Evans fest, dass die Terminologie der Informatiker von der Terminologie der Platinenlayouter unterschiedlich war. Im Bereich der Informatik hat es sich deshalb an vielerlei Stelle eingebürgert, die Subject Matter Experts nach bestem Wissen und Gewissen von UML-Diagrammen und ähnlichen Nettigkeiten der Softwarearchitektur fernzuhalten. Durch diese Duplizierung entsteht ein fragmentiertes Bild der Applikationsdomäne – der Subject Matter Expert ist nicht mehr in der Lage, die vom IT-Teil des Teams generierten Dokumente direkt anzusehen und auf fachliche Korrektheit zu überprüfen.

Die von Eric Evans vorgeschlagene Lösung ist das Konzept der Ubiquitous Language (UL). Hinter dem englischen Begriff verbirgt sich so etwas wie eine „universelle Sprache“. Im Prinzip handelt es sich dabei um eine Art Glossar, das technische Begriffe sowohl im Bereich der Domäne als auch im Bereich der IT festgelegt. Sinn dieser gemeinschaftlichen Sprache, die sowohl im Bereich des Modells als auch im Code verwendet werden soll, ist, dass Subject Matter Expert und Entwickler fortan besser zusammenarbeiten.

Eines der expliziten Ziele des Domain-driven Design ist es, dass die Konsistenz zwischen Modell und realisierter Software auch dann erhalten bleibt, wenn die Entwicklung des Prozesses iterativ ist oder Veränderungen erfährt. Schon hier sei darauf hingewiesen, dass die Beschränkung von Domain-driven Design auf die Rolle einer Sammlung von Designpatterns nicht im Sinne des Entwicklers ist. Das im Jahre 2015 erschienene Patterns, Principles and Practices of Domain-driven Design formuliert sogar explizit, dass man Domain-driven Design eher als eine „Anleitung zur Kommunikation“ sehen sollte.

Sammlung der Modelle (Context, Bounded Context)

Die soeben durchgeführten grundlegenden Überlegungen zur UL zeigen, dass Domain-driven Design wahrscheinlich nicht bei sehr simplen Systemen zum Einsatz kommt – eine Software, die eine Lampe ein und ausschaltet, bekommt ein Normalentwickler auch ohne DDD-Unterstützung hin.

Ab einer gewissen Problemgröße gilt allerdings, dass man das System nicht mehr en bloc im Kopf behalten kann. Man muss die Problemdomäne deshalb stufenweise unterteilen – dabei stehen allerdings mehrere Methoden zur Verfügung. Ein gutes Beispiel wäre ein System zur Verwaltung einer imaginären Drohnenfluglinie, das nach dem in Abbildung 2 gezeigten Schema in „logische“ Domänen aufgeteilt wird.

hanna_ddd_2.tif_fmt1.jpgAbb. 2: Unsere Minifluglinie benötigt verschiedene Funktionen

Die Verständigung bereitet an dieser Stelle Probleme – ein Ticket könnte sich im Fall unserer Miniairline sowohl auf einen Zerstörungsauftrag als auch auf eine Reparatur an einer der Bomberdrohnen beziehen. Die Lösung des Problems in der Welt von Domain-driven Design ist der Bounded Context, ein von seiner Umgebung getrennter und über definierte Interfaces mit ihr verbundener Teil der Gesamtlösung.

Im Zusammenspiel mit einer Context Map erlauben Bounded Contexts zudem die Vereinfachung des Modells, was zu einfacherer Wartbarkeit und weniger Problemen bei der Umsetzung von Anpassungen führt. Zur „Unterteilung“ der Problemdomäne empfehlen Millett und Tune derweil ...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang