Domain-Driven Design: Software in eurer Sprache

Teil 2 der Reihe "Software gemeinsam gestalten". Zur Übersicht

Im ersten Teil haben wir beschrieben, warum Fachleute von Anfang an in die Softwaregestaltung gehören. Domain-Driven Design (DDD) liefert den Denkrahmen, der das möglich macht. Eric Evans hat ihn 2003 beschrieben, und die Kernideen sind heute relevanter denn je: Software entlang der Fachlichkeit schneiden und die Sprache des Teams in den Code bringen.

Die Kernidee

Domain-Driven Design stellt die Fachdomäne ins Zentrum der Softwareentwicklung. Die Domäne ist der Ausschnitt der Welt, in dem eure Organisation arbeitet: Fundraising, Logistik, Bildung, Gesundheit. Das Ziel ist eine Software, deren Struktur diese Domäne widerspiegelt, sodass fachliche Änderungen sich in nachvollziehbaren Code-Änderungen niederschlagen.

Dafür braucht es zwei Dinge: ein gemeinsames Verständnis der Domäne und eine Sprache, die dieses Verständnis transportiert. Beides entsteht im Gespräch zwischen Fachleuten und Entwickler:innen und fließt direkt in den Code.

Strategisches und taktisches DDD

DDD unterscheidet zwei Ebenen. Die strategische Ebene beantwortet die Frage: Wie schneiden wir die Software, damit sie zur Organisation passt? Hier geht es um Bounded Contexts (abgegrenzte Fachbereiche mit eigenem Modell), um die Beziehungen zwischen diesen Kontexten und um die gemeinsame Sprache innerhalb jedes Kontexts.

Die taktische Ebene beschreibt Bausteine innerhalb eines Kontexts, also die Art, wie fachliche Regeln und Zusammenhänge im Code abgebildet werden. Für den Einstieg ist die strategische Ebene wichtiger, weil sie den Schnitt vorgibt, der alle weiteren Entscheidungen beeinflusst.

Drei Säulen in der Praxis

1. 01

   Gemeinsame Sprache

   Fachleute und Entwickler:innen verwenden dieselben Begriffe, im Gespräch und im Code. Wenn der Code "Zuwendungsbestätigung" sagt und das Team "Zuwendungsbestätigung" sagt, sinkt die Fehlerquote, weil Übersetzungsverluste wegfallen.

2. 02

   Fachlicher Schnitt

   Die Software wird entlang fachlicher Grenzen geschnitten, etwa nach Verantwortungsbereichen oder Geschäftsprozessen. Jeder abgegrenzte Fachbereich (Bounded Context) hat sein eigenes Modell, das genau die Komplexität abbildet, die er braucht.

3. 03

   Modell im Code

   Das Fachmodell lebt im Code, in den Bezeichnungen, Regeln und Abläufen der Software. Der Code ist eine lesbare Beschreibung der Domäne, die sich mit dem Fachverständnis weiterentwickelt.

Was DDD verändert

Teams, die domain-driven arbeiten, treffen Architekturentscheidungen auf fachlicher Grundlage. Die Module im Code decken sich mit den Zuständigkeiten im Team. Änderungen an einem Geschäftsprozess betreffen einen klar abgegrenzten Teil der Software. Und neue Teammitglieder finden sich schneller zurecht, weil der Code die Fachsprache spricht.

Software, die eure Sprache spricht, lässt sich gemeinsam weiterentwickeln.

Vom Denkrahmen zum Werkzeug

DDD beschreibt das Ziel: Software, die die Domäne widerspiegelt. Doch wie kommt ein Team zu einem gemeinsamen Bild der Domäne? Im nächsten Teil stellen wir Event Storming vor, das Workshop-Format, mit dem wir diesen Denkrahmen in die Praxis bringen.