© 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 fest...

Neugierig geworden?

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