Wie wir mit Domain-Driven-Design Missverständnisse besiegen

Lena, eine erfahrene Softwarearchitektin, war mit einem neuen Projekt konfrontiert – einem Mammutprojekt zur Digitalisierung der Lieferkette eines großen Online-Händlers. Schnell merkte sie, dass die größte Herausforderung nicht die Technik, sondern die Kommunikation war. Jeder sprach seine eigene Sprache: Was für den Vertrieb ein „Kunde“ war, hatte für die Buchhaltung oder das Lager ganz andere Facetten. Dieses Durcheinander führte zu Fehlern, Verzögerungen und Frustration.
Lena wusste: Bevor Software entstehen konnte, musste ein gemeinsames Verständnis her.

Um das Problem für alle im Team greifbar zu machen, nutzte Lena in einem Workshop eine Metapher: die einer Restaurantküche im Hochbetrieb.

„Stellt euch vor,“ sagte sie, „ein Kellner kommt in die Küche und hängt einen Bon an die Leiste. Darauf steht: Tisch 7: 1x Steak, Spezial.“

Sie malte die möglichen Interpretation des Bons an ein Whiteboard:

• Der neue Koch sieht „Spezial“ und denkt, der Gast wünscht sich eine besonders schöne Garnitur. Er fügt ein kunstvolles Rosmarinsträußchen hinzu.

• Die erfahrene Sous-Chef weiß, dass „Spezial“ seit jeher die geheime Pfeffersoße des Hauses bedeutet, die nicht auf der Karte steht. Sie bereitet das Steak mit dieser Soße zu.

• Die Chefköchin hat am Morgen das „Tages-Spezial“ angekündigt – ein Steak mit Trüffelbutter. Für sie ist klar: „Spezial“ kann nur das bedeuten.

„Das Ergebnis,“ schloss Lena, „wäre Chaos! Der Gast, der mit ‚Spezial‘ eigentlich nur meinte, dass sein Steak ‚ohne Zwiebeln‘ zubereitet werden soll, erhält eine völlig falsche Bestellung.“ Sie sah in die Runde. „Genau das erleben wir hier jeden Tag. Begriffe wie ‚Lieferung‘, ‚Produkt‘ oder ‚Bestellung‘ sind unser ‚Spezial‘. Das Wissen darüber, was wirklich gemeint ist, geht bei der Übergabe von einer Abteilung zur nächsten verloren.“

Die gemeinsame Sprache (Ubiquitous Language)

Lena stieß auf das Domain-Driven Design (DDD), das eine klare Botschaft hatte: Die Software muss das Geschäft so widerspiegeln, wie die Fachexperten es verstehen. Der erste und entscheidende Schritt war die Einführung einer gemeinsamen Sprache – auch bekannt als „Ubiquitous Language„

Lena versammelte alle Schlüsselpersonen: Fachexpert:innen, Produktmanager:innen und Entwickler:innen. Gemeinsam begannen sie, jeden wichtigen Geschäfts-Begriff präzise zu definieren.

Das Ziel war es, eine Sprache zu schaffen, die überall verwendet wird:

• In Gesprächen: Keine Abteilung sollte mehr an der anderen vorbeireden.
• In Dokumenten: Alle Spezifikationen und Anleitungen wurden in dieser einheitlichen Sprache verfasst.
• Im Quellcode: Die Software selbst sollte diese Sprache sprechen, um transparent und verständlich zu sein

Dieser Prozess war anfangs mühsam, doch die Vorteile zeigten sich schnell:

• Weniger Missverständnisse: Die ständige Notwendigkeit der „Übersetzung“ entfiel
• Schnellere Entwicklung: Entwickler verstanden die Geschäftsanforderungen besser und konnten präziser arbeiten.
• Bessere Qualität: Da das Verständnis klar war, wurden weniger Fehler gemacht, die auf falschen Annahmen beruhten.
• Effizientere Einarbeitung: Neue Teammitglieder konnten sich schneller in das Projekt einfinden, da eine einheitliche Terminologie existierte

Fazit

Die Einführung der gemeinsamen Sprache war mehr als nur eine technische Massnahme; sie war eine strategische Entscheidung, die das Fundament für den Projekterfolg legte. Sie stellte sicher, dass alle Beteiligten – vom Management bis zum Entwicklungsteam – dasselbe Bild vor Augen hatten, wenn sie über das System sprachen. Es war der erste Schritt, um die Komplexität des Großprojekts beherrschbar zu machen und eine klare Vision zu schaffen

Lenas Erfahrung zeigte, dass eine klar definierte und konsequent angewendete gemeinsame Sprache der Schlüssel zur Überwindung von Kommunikationsbarrieren ist. Sie ermöglicht es Teams, sich auf das Wesentliche zu konzentrieren: die Entwicklung von Software, die das Geschäft präzise unterstützt und weiterbringt. Die gemeinsame Sprache ist das Herzstück jedes erfolgreichen Softwareprojekts, da sie das gemeinsame Verständnis fördert und alle Stakeholder auf denselben Weg bringt.

Referenzen

• Vladik Khononov: Learning Domain-Driven Design
• Eric Evans: Domain-Driven Design: Tackling Complexity in the Heart of Software
• Vaughn Vernon: Implementing Domain-Driven Design