Was ist eigentlich Domain Driven Design (DDD)?

ddd_header

Nahezu jedes Software-System arbeitet mittlerweile in einem komplexen und dynamischen Umfeld. Kundenwünsche, Marktfaktoren und Technologien ändern sich schneller als je zuvor, so dass eine anpassungsfähige IT zum entscheidenden Erfolgsfaktor wird. Der stetige Wandel macht den Aufbau von aktuellem Domänenwissen für Entwickler mühsam. Die Folge: Softwareentwicklungen gehen immer häufiger an den Vorstellungen des Auftraggebers vorbei, da die Kommunikation zwischen Entwicklern und Fachleuten an Verständnisproblemen leidet. Ein populärer Lösungsansatz für diesen Konflikt ist Domain Driven Design.

Domain Driven Design: Revival eines IT-Klassikers

Auch wenn Domain Driven Design derzeit einen Hype erlebt, ist das Konzept nicht neu. Der Begriff wurde bereits 2003 durch Eric Evans geprägt, als dieser mit seinem Buch „Domain-driven Design: Tackling Complexity in the Heart of Software“ einen IT-Klassiker veröffentlichte. Seine Kernidee: Die Geschäftsabläufe, die mit der Software abgebildet werden sollen, rücken in den Mittelpunkt der Entwicklung. Oder anders formuliert: Ask the Business! Um Prozesse zu unterstützen oder zu optimieren, müssen Entwickler das Geschäftsfeld des Kunden grundlegend verstehen. Technologische Entscheidungen werden so spät wie möglich getroffen.

„Wenn wir Software entwickeln, sollte unser Fokus nicht primär auf den Technologien liegen, die wir verwenden. Stattdessen sollte sich unser Hauptaugenmerk auf die geschäftliche Seite richten, also auf den fachlichen Bereich, den wir mit unserer Software unterstützen wollen – kurz: auf die Domäne.“
Eric Evans

Domain Driven Design gibt interdisziplinären Teams eine gemeinsame Sprache an die Hand, die die Kommunikation vereinfacht und Missverständnisse vermeiden hilft.

Welche Bausteine setzt DDD für eine effizientere Kommunikation ein?

Ziel ist die gemeinsame Entwicklung eines Domänenmodells, das von allen Projektbeteiligten verstanden wird. Stark vereinfacht umfasst es alle relevanten Fachobjekte („Entities“), Eigenschaften („Value Objects“) und deren Beziehungen („Assoziationen“) untereinander. Dabei bildet das Modell immer nur einen Ausschnitt der Domäne ab – aber mit allen für die Implementierung wichtigen Aufgaben, Abhängigkeiten und Zusammenhängen.

  • Entities sind Modellobjekte, die eine konstante, eindeutige und langfristige Identität besitzen (beispielsweise Konto, Kunde, Auto o.ä.)
  • Value Objects sind Eigenschaften ohne Identität (beispielsweise Wochentag, Anzahl, Betrag o.ä.)

Wichtig: Das Domänenmodell ist nicht von Anfang an perfekt, sondern ein lebendiger „Wissenspool“, der mit der Software mitwächst. Nachdem die erste Version des Modells von Fachexperten und Entwicklern erarbeitet wurde (z. B. an einem Whiteboard), kann es schrittweise in den Quellcode überführt werden – in agilen Teams meist in Sprints. Dieser Prozess führt zu einem systematischen Aufbau von Fachwissen bei den Entwicklern, aber auch zu einem besseren Verständnis für technische Fragestellungen bei den Fachexperten.

Mit entsprechenden Tools kann der Quellcode auf Knopfdruck als Grafik oder Dokumentation (z. B. Tabelle) ausgegeben werden, so dass der Status Quo der Domäne jederzeit für alle Beteiligten sichtbar ist.

Welches Vokabular wird im Domain Driven Design benutzt?

„To create a supple, knowledge-rich design calls for a versatile, shared team language“
Eric Evans
 
Die Grundlage für das interdisziplinäre Modellieren einer Fachdomäne ist eine gemeinsame, formalisierte Sprache, die keinen Raum für Fehlinterpretationen lässt – die sogenannte „ubiquitäre Sprache“ (ubiquitär = allumfassend / überall vorhanden). Die Ubiquitous Language geht über ein herkömmliches Glossar hinaus: Alle Projektbeteiligten sollen die festgelegten Ausdrücke aktiv verwenden, um Anforderungen zu diskutieren und Lösungen zu formulieren. Bei Bedarf können auch eigene Begriffe erfunden werden, um einen Sachverhalt eindeutig und verständlich zu beschreiben.

Die ubiquitäre Sprache entsteht durch Diskussionen, in denen Fachbegriffe und Prozesse hinterfragt und ihre Bedeutung erklärt und exakt abgegrenzt wird. Wichtig: Die ubiquitäre Sprache ist immer kontextabhängig. Beispielsweise kann mit „Freelancer“ je nach Kontext ein Mitarbeiter oder ein Dienstleister gemeint sein.
 

Welche Vorteile generiert Domain Driven Design?

Domain Driven Design wird seit über zehn Jahren erfolgreich für Enterprise Softwareentwicklung eingesetzt und erlebt im Zuge von Microservices-Architekturen eine Renaissance. Insbesondere in der Software-Wartung und bei der Bearbeitung von Support-Anfragen entfaltet Domain Driven Design sein volles Potenzial.

Ändern sich die Software-Anforderungen, hilft das Domänenmodell, die betroffenen Fachobjekte schnell und eindeutig zu identifizieren und die Updates an der richtigen Stelle des Quellcodes einzufügen. Auch die Kommunikation mit dem Support wird vereinfacht, beispielsweise beim Debugging. Die Release-Quote kann so erfahrungsgemäß deutlich erhöht und die Qualität von Software verbessert werden.

Passen Domain Driven Design und Agilität zusammen?

Agile Methoden und Domain Driven Design harmonieren hervorragend! Beide Mindsets basieren auf einem iterativen und empirischen Ansatz, fordern ein kontinuierliches Lernen und fördern eine intensive, crossfunktionale Kommunikation. Die iterative und inkrementelle Verbesserung des Domänenmodells führt zu einer robusten und flexiblen Software mit einem maximalen Mehrwert für den Nutzer – wichtige Erfolgsfaktoren in dynamischen und wettbewerbsintensiven Märkten.

Sie möchten die Geschwindigkeit Ihrer Softwareentwicklung erhöhen oder die Kommunikation im Team verbessern? Fragen Sie uns, wir unterstützen Sie gerne dabei, Domain Driven Design als Brücke zwischen Fachexperten und Entwicklern einzusetzen!

Bildnachweis:
Cartoon: www.projectcartoon.com
Header: 123rf.com/radachynskyi

Teamprove Insights: Unsere OKR 2018
O-TON: 10 Fragen an Christoph Dibbern