# Domain Driven Design[^1][^2] - (12.02.2025) Als Software Entwickler finden wir uns immer wieder in Situationen, in welchen ein Verständnis der Geschäftsdomäne nötig ist, um die Komplexität des Projekts handhaben zu können. DDD bietet einen strukturierten Weg, um mit diesen Komplexitäten umgehen zu können, durch einen strukturierten Weg in welchem wir uns auf die Kern-Geschäftslogik fokussieren. DDD ist jedoch nicht nur eine Methodik, sondern eine Denkweise. ## Was ist Domain Driven Design? Domain Driven Design ist eine Philosophie in der Software Entwicklung welche von Eric Evans 2003 eingeführt wurde. Es geht dabei darum, eine stärkere Verbindung zwischen der Software und der Geschäftsdomäne für welche sie entwickelt wurde zu zu fördern. Die Kern Idee ist es, eine Software zu entwickeln welche die Geschäftskonzepte, -regeln und -prozesse abbildet. Das Ziel lieft darin, eine Software zu entwickeln welche sowohl bedeutungsvoll aber auch nützlich für den Benutzer ist. ## Kern Konzepte von DDD ### *Core Domain* (Kerndomäne): Die Kerndomäne ist die zentrale Expertise welche einzigartig und relevant für das Geschäft ist. Diese Domäne erhält am meisten Aufmerksamkeit und Ressourcen während der Entwicklung. Die Kerndomäne zu identifizieren hilft dabei, den Fokus auf die effektiven Unterschiede eines Geschäfts gegenüber der Konkurrenz zu legen. ### Domain Model (Domänenmodell): Das Domänenmodell ist eine konzeptionelle Representation der Geschäftsdomäne. Enthalten sind Entitäten, Wertobjekte (*value objects*) und Services. Dieses Modell dient als Anleitung für das Software Design. Das Domänenmodell sollte viele Verhalten erfassen und die Geschäftslogik einkapseln. So wird das Verständnis der Software einfacher, was auch eine Erweiterung fördert. ### Ubiquitous Language (Allgegenwärtige Sprache): Die allgegenwärtige Sprache sollte als Kommunikationsmittel zwischen den Entwicklern und den Domänenexperten dienen um das Domänenmodell und Systemanforderungen zu beschreiben. So kann sichergestellt werden, dass alle Beteiligten das gleiche Verständnis der Domäne haben. Missverständisse können mit einer geteilten Sprache minimiert werden und es existiert weniger Raum für Interpretation. ### Bounded Contexts (Begrenzte Kontexts): Grosse Systeme können in kleinere, unabhängige Modelle aufgeteilt werden, welche jeweils nur einen spezifischen Teil der Domäne repräsentieren. So wird die Komplexität gesenkt, da sichergestellt wird, dass jeder Kontext seine klaren Abgrenzungen und Definitionen hat. Begrenzte Kontexts sind wichtig um das Verständnis in einer komplexen Domäne zu bewahren. ### Collaboration (Kollaboration): DDD fördert die Zusammenarbeit zwischen technischen Experten und Domänenexperten. Zusammen können die Domänenmodelle iterativ verbessert werden, um sicher zu stellen, dass sie weiterhin die Geschäftsdomäne akkurat repräsentieren. Diese Zusammenarbeit sollte über den ganzen Prozess bestehen um die Software auf einem Zielgerichteten Pfad zu halten. ## Vorteile von DDD Wir haben uns jetzt die Kernkonzepte von DD angeschaut. Durch Einhaltung dieser profitieren wir von vielen Vorteilen: ### Bessere Kommunikation: Durch die allgegenwärtige Sprache wird die Kommunikation nicht nur gefördert, sondern die Qualität auch verbessert. Wie bereits erwähnt, geschehen mit der geteilten Sprache weniger Fehler und Missverständnisse. Die klare Sprache hilft jedoch auch den Entwicklern, die Anforderungen besser und genauer umzusetzen. ### Unterhaltbarkeit Software welche mit DDD entwickelt wurde ist einfacher zu unterhalten, da sie um die Geschäftsdomäne strukturiert ist wodurch sie einfacher zu verstehen und verändern ist. Wenn sich Geschäftsanforderungen ändern können auch die Domänenmodelle entsprechend angepasst werden um die Veränderung direkt in der Entwicklung wieder zu spiegeln. ### Relevanz DDD stellt sicher, dass die Software Features mit den Geschäftsanforderungen übereinstimmen. So können Geschäfte ihre Ziele effektiver und effizienter erreichen. ### Flexibilität Da sich das Domänenmodell fortlaufend anpassen kann, bietet DDD eine grosse Flexibilität. Die Software kann sich an alle geschäftlichen Änderungen anpassen und mit dem Unternehmen wachsen. ## DDD in der Praxis Um DDD in einem Projekt ein zu setzten, können wir das ganze in folgende Schritte einteilen: 1. Die Domäne verstehen 2. Die Domänenmodelle entwickeln 3. Eine allgegenwärtige Sprache vereinbaren 4. Das Projekt in begrenzte Kontexte aufteilen 5. Iterieren und verbessern Während diese Schritte auf den ersten Blick sehr übersichtlich aussehen und die Vorteile für die meisten Projekte ansprechend tönen sollten, kommt DDD nicht ohne Kosten. So gibt es einige Herausforderungen welche bei der Wahl von DDD als Methodik bedacht werden müssen. Beispiele für solche währen: 1. **Initiale Komplexität**: DDD ist in der Praxis sehr komplex und muss zuerst vom ganzen Team verstanden werden. Ist kein Verständnis vorhanden, kann DDD nicht effektiv eingesetzt werden und viele der Vorteile gehen verloren. 2. **Domänenexpertise**: Tiefes Domänenverständnis zu erlangen ist sehr zeitintensiv und verlangt eine starke Zusammenarbeit von Entwicklern und Experten. Diese Kosten können den Nutzen von DDD übersteigen und einen Einsatz der Methodik nicht lohnenswert machen. 3. **Widerstand gegen Änderung**: Viele Teams zeigen sich abgeneigt gegenüber grossen Änderungen was eine Adaption von DDD schwierig macht. Ohne Kooperation von allen Mitarbeitern kann DDD auch nicht effektiv eingesetzt werden. ## Fazit DDD ist eine sehr mächtige Vorgehensweise um Software zu entwickeln welche die Anforderungen der Kunden genau widerspiegelt. Da der Fokus auf der Geschäftsdomäne liegt und eine Zusammenarbeit von technischen Experten und Domänenexperten gefördert wird, entwickelt man Software die nicht nur bedeutungsvoll sondern auch unterhaltbar ist. Viele der genannten Schwierigkeiten können durch Weiterbildungen adressiert werden. Wenn sich die dadurch entstandenen Kosten für ein Projekt lohnen, sollte dies definitiv in Betracht gezogen werden. DDD ist aber kein Wundermittel von welchem jedes Projekt profitiert. Wie immer, muss ein Einsatz in Anbetracht aller Faktoren des Projekts abgewägt werden. [^1]: vgl. What is DDD?, in: Domain-Driven Design Europe, 12.02.2025, https://www.youtube.com/watch?v=pMuiVlnGqjk [^2]: Starke, Gernot: "Domain-Driven Design" Effektive Softwarearchitekturen: Ein praktischer Leitfaden, München, Deutschland: Carl Hanser Verlag, 2020, pp. 84 - 89