Lesezeit ca. 7 Minuten
Hier auch als Podcast:
Einleitung
Domain Driven Design (DDD oder Triple D) auch bekannt als domänengesteuertes Design, wird seit mehr als 20 Jahren als Methode empfohlen, um Entwickler und Business einander näherzubringen und die Wertschöpfung zu erhöhen.
Was ist DDD und worin besteht der Mehrwert für da Business?
In der IT werden immer wieder neue, bzw. vermeintlich neue Methoden beworben, welche das Arbeiten erleichtern sollen und schneller zu wertvollen Ergebnissen führen. Dies ist kein neues Phänomen.
In letzter Zeit ließ sich beobachten, dass in der Softwareentwicklung DDD bzw. Domain Driven Design wieder verstärkt in den Fokus gerückt ist. Wobei anzumerken ist, dass DDD bereits in den späten ’90 Jahren des vorigen Jahrhunderts entstanden ist. Das Buch von Eric Evans: “Domain-Driven Design: Tackling Complexity in the Heart of Software”, welches bereits 2003 erschienen ist, gilt auch heute noch als Standardwerk zu diesem Thema.
Domain Driven Design (DDD) ist eine Herangehensweise für die Softwareentwicklung, bei der der Schwerpunkt auf der Analyse und Modellierung des Fachbereichs (Domain) liegt. Das Ziel ist es, eine bessere Verbindung zwischen der Fachsprache der Nutzenden und der Software zu schaffen, um so wirksamere und wirtschaftlichere Lösungen zu entwickeln.
Bevor wir tiefer in dieses Thema einsteigen, möchte ich vorab auf ein paar Fachbegriffe aus dem DDD eingehen, da sie eine zentrale Rolle spielen. Um das Fachwissen in die Softwareentwicklung zu integrieren, identifiziert DDD zuerst die wichtigsten Konzepte (Entities) und deren Beziehungen untereinander (Relationships). Dabei werden auch Fachbegriffe und -prozesse (Business Processes) definiert und modelliert. Das angestrebte Ergebnis ist eine gemeinsame Sprache zwischen den Fachleuten und den Entwickelnden, die in DDD als “Ubiquitous Language“ bezeichnet wird. Diese gemeinsame Sprache soll im weiteren Verlauf dem reibungslosen Austausch zwischen allen Beteiligten dienen.
Auf dieser Basis können dann die Softwarekomponenten (Services) so aufgebaut werden, dass sie die Fachprozesse abbilden und die Anforderungen des Fachbereichs erfüllen. Die Services werden in einem begrenzten Kontext (Bounded Context) betrachtet, um Klarheit über deren Aufgaben und Verantwortlichkeiten zu schaffen. Dabei wird auch darauf geachtet, dass die Abhängigkeiten zwischen den Services minimiert werden.
DDD betont auch die Wichtigkeit von Feedback und ständiger Anpassung des Modells. Dies kann durch die Zusammenarbeit von Fachleuten und Entwicklern im Team und durch die Nutzung von Tools wie z.B. Event Storming erreicht werden.
An dieser Stelle kann man sehen, wie Ideen, die üblicherweise agilen Methoden zugeschrieben werden, bereits in DDD vorkommen. Daher ist die Integration von DDD in einen agilen Rahmen, wie bspw. Srum, SAFe oder LeSS nicht nur möglich, sie wird sogar empfohlen.
1. Was benötigt man im Vorfeld?
Wenn man sich entscheiden sollte, DDD anzuwenden, dann gilt es im Vorfeld sich über ein paar Dinge klar zu werden und in der Folge auch umzusetzen. Hier einige ausgewählte Punkte als Beispiel:
- Verstehe den Fachbereich: Domain Driven Design basiert auf einem tiefen Verständnis des Fachbereichs, daher ist es wichtig, Zeit in die Analyse und das Verständnis der Geschäftsprozesse und -regeln zu investieren, um schließlich softwareseitig die “Business Logic“ modellieren zu können.
- Definiere eine einheitliche Sprache, die sog. „Ubiquitous Language“: Eine einheitliche Sprache, die von Fachleuten und Entwicklern gleichermaßen verstanden wird, ist entscheidend, um Missverständnisse und Fehlinterpretationen zu vermeiden. Dies ist natürlich eine allgemeine Empfehlung, die man immer geben kann, dennoch ist sie wertvoll und notwendig. Abgesehen davon ein fester Bestandteil von DDD.
- Nutze Feedback und Anpassungen (hier wird es tendenziell agil): Die kontinuierliche Verbesserung des Modells ist ein wichtiger Aspekt von DDD. Feedback aus der Praxis und Anpassungen des Modells sind absolut notwendig, um sicherzustellen, dass es den Anforderungen des Fachbereichs entspricht. An dieser Stelle sei noch einmal betont, dass Feedback ohne den oben genannten Punkt 2 nicht viel Sinn macht.
2. Was sollte man vermeiden?
Leider hat sich in der Vergangenheit gezeigt, dass bei der Einführung und anschließenden Anwendung von DDD auch einiges falsch gemacht werden kann. Auch hier ein handvoll Beispiele:
- Übermodellierung: Eine Übermodellierung kann dazu führen, dass das Modell zu komplex wird und sowohl die Entwickelnden als auch die Fachleute überfordert. Es ist wichtig, ein ausgewogenes Verhältnis zwischen Abstraktion und Details zu finden und sich auf die wichtigsten Konzepte und Prozesse zu konzentrieren.
- Fehlende Zusammenarbeit zwischen Fachleuten und Entwickelnden: Die Zusammenarbeit zwischen Fachleuten und Entwickelnden ist ein wichtiger Baustein von DDD. Damit soll sichergestellt werden, dass das Modell den Anforderungen des Fachbereichs entspricht. Eine fehlende Zusammenarbeit kann dazu führen, dass das Modell nicht korrekt ist und die Softwarelösung nicht den Anforderungen des Fachbereichs entspricht.
- Fehlende Dokumentation (ein Klassiker): Eine unzureichende Dokumentation des Modells und der Umsetzung kann dazu führen, dass die Softwarelösung schwer zu verstehen und zu warten ist. Es ist wichtig, eine angemessene, immer aktuelle Dokumentation zu erstellen, um sicherzustellen, dass das Modell und die Implementierung für alle Beteiligten leicht zugänglich, verständlich und letztlich anwendbar sind.
3. Was sollte man tun, damit es klappt?
Auf der anderen Seite gibt es aber auch Dinge, die den erfolgreichen Einsatz der Methode unterstützen, bzw. dabei helfen, mit DDD Erfolg zu haben. An dieser Stelle wieder ein paar ausgesuchte Beispiele:
- Abstraktion und Modularisierung (dieser Punkt ist vor allem für die Entwickelnden wichtig!): Eine klare Abstraktion und Modularisierung des Systems ist wichtig, um die Komplexität zu reduzieren und sicherzustellen, dass jede Komponente klare Verantwortlichkeiten hat und unabhängig voneinander entwickelt und gewartet werden kann.
- Continuous Integration und Deployment (jetzt bewegen wir uns im Gebiet von DevOps): Die kontinuierliche Integration und das Deployment der Software ist ein wichtiger Faktor, um sicherzustellen, dass das System immer auf dem neuesten Stand ist und die Änderungen schnell und zuverlässig in Produktion übernommen werden können.
- Agile Methoden: Agile Methoden wie Scrum und / oder Kanban können dazu beitragen, dass das Projekt flexibel und anpassungsfähig bleibt und die Entwicklung schnell auf sich verändernde Anforderungen des Fachbereichs reagieren kann.
Abschließend stellt sich die Frage, was hat das Business davon? Was ist der Mehrwert? Kann die Einführung und Anwendung von DDD überhaupt auf Geschäftsziel einzahlen? Auch hier gibt es einige stichhaltige Argumente:
- Bessere Flexibilität und Anpassungsfähigkeit: Durch die Verwendung von agilen Methoden und eine klare Abgrenzung der Kontexte kann das System flexibler und anpassungsfähiger auf sich ändernde Geschäftsanforderungen reagieren. Dadurch werden zusätzliche Aufwände und Kosten reduziert.
- Kürzere Time-to-Market: Durch die Verwendung von agilen Methoden und einer besseren Zusammenarbeit zwischen Fachexpertinnen und Fachexperten und Entwicklerinnen und Entwicklern können neue Funktionen und Produkte schneller und effizienter entwickelt und auf den Markt gebracht werden. In anderen Worten ausgedrückt: Mit geringerem Aufwand, mehr Ertrag!
- Verbessertes Risikomanagement: Durch die Verwendung von Domain Driven Design kann das Risiko von Fehlern und Fehlfunktionen im System reduziert werden, da die Implementierung enger an den Geschäftsanforderungen ausgerichtet ist. Die Gefahr, Geld ohne Gegenwert ausgeben zu müssen, wird verringert.
Lucke EDV GmbH hat über viele Jahre hinweg einen reichhaltigen Erfahrungsschatz und Umsetzungskompetenz bezüglich Einführung und Anpassung komplexer Systeme aufgebaut. Wir als Unternehmen sowie der Autor dieses Beitrags stehen Ihnen gerne hierzu mit unseren Fähigkeiten und Kompetenzen zur Verfügung.
Ihr Ansprechpartner:
Aleksandar Radonjic | Management Consultant & Business Analyst | aleksandar.radonjic@lucke-edv.de
Lucke EDV GmbH | Zurück
