Domain-driven Design (domänengesteuertes Design)

Was ist Domain-driven Design (domänengesteuertes Design)?

Domain-driven Design (DDD) oder domänengesteuertes Design ist eine Softwareentwicklungsphilosophie, die sich auf den Geschäftsbereich oder Wissensbereich der Benutzer dieser Software konzentriert. DDD betont die Bedeutung des Verständnisses und der Modellierung des Geschäftsbereichs, für den eine Softwareanwendung entwickelt wird.

Eric Evans erklärte das Konzept erstmals in seinem Buch Domain-Driven Design: Tackling Complexity in the Heart of Software (PDF). Dieses 2003 veröffentlichte Buch enthält zahlreiche Schemata, Repositories, Wertobjekte und Entitäten, die Entwickler dabei unterstützen können, ein aussagekräftiges und objektorientiertes Programmiermodell (OOP) zu erstellen, das auf das Unternehmen und seine Bedürfnisse abgestimmt ist. Die Grundidee von DDD besteht darin, Software an den Geschäftsanforderungen auszurichten, die sie erfüllen soll, und so ihre Qualität und Benutzerfreundlichkeit zu verbessern.

Da es bei Domain-driven Design darum geht, den spezifischen Geschäftskontext zu berücksichtigen, in dem die Software eingesetzt werden soll, wird die Verwendung einer allgegenwärtigen oder gemeinsamen Sprache sowohl für Softwareentwickler als auch für Geschäftsinteressenten betont. Infolgedessen spiegelt unter anderem jede Klasse, Methode und Variable im Softwarecode die Geschäftsrealität wider und fördert das Geschäftsverständnis, wodurch sichergestellt wird, dass das Programm für Geschäftsanwender verständlich und in dem Bereich, für den es entwickelt wurde, nutzbar bleibt.

Domain-driven Design fördert auch die iterative Zusammenarbeit. Durch die enge Zusammenarbeit untereinander und mit dem Unternehmen können Entwickler Software erstellen, die das Unternehmen, für das sie bestimmt ist, besser widerspiegelt. Der iterative Entwicklungsansatz führt oft zu einer besseren Qualität der Software, die auf die Geschäftsanforderungen abgestimmt ist.

Zusammengefasst lauten die vier Hauptideen des Domain-driven Designs:

1. Kerndomäne. Der Geschäftsbereich und seine grundlegenden Aspekte – Elemente, Entitäten, Anforderungen, Ziele – sollten auf die zu entwickelnde Software abgestimmt sein.
2. Modellgetriebene Entwicklung. Ein gut definiertes Domänenmodell stellt die Geschäftsdomäne dar und dient als Grundlage für die Softwareentwicklung für diese Domäne.
3. Allgegenwärtige Sprache. Eine gemeinsame Sprache erleichtert die Kommunikation zwischen den technischen – das heißt den Entwicklungs- – und den Geschäftsteams.
4. Iterative Zusammenarbeit. Kontinuierliche iterative Zusammenarbeit zwischen Entwicklern und Stakeholdern aus dem Geschäftsbereich, um Erkenntnisse auszutauschen, Feedback zu geben und eine kontinuierliche Verbesserung der Software zu ermöglichen.

Domain-driven Design und Geschäftsdomänen

Um aus einer Perspektive des Domain-driven Designs etwas zu entwickeln, muss der Geschäftsbereich oder die Domäne des Unternehmens definiert werden. Es gibt unterstützende und Kerndomänen. Die Kerndomäne eines Unternehmens ist einzigartig und von zentraler Bedeutung für seinen Betrieb, weshalb sie den Großteil der Aufmerksamkeit, Zeit und Ressourcen im Entwicklungsprozess erhält. Die unterstützenden Domänen sind allgemeiner, wie zum Beispiel Geld, Service oder Zeit.

Diese Bereiche werden dann in Sprache und entsprechenden Code modelliert. Wenn ein Bereich nicht einfach in Sprache definiert werden kann, ist er nicht bereit für die Codierung. Wenn in einem Geschäftsbereich eine Änderung eintritt, ist in der Regel eine entsprechende Codeänderung erforderlich.

Bedeutung des Domain-driven Designs

Domain-driven Design kann bei komplexen Projekten mit komplexer Geschäftslogik von großem Nutzen sein. Der Ansatz ermöglicht die Entwicklung von Software, die sich auf die Anforderungen der Benutzer konzentriert, die sie benötigen. Mit seinem Schwerpunkt auf der Erstellung eines Domänenmodells, der Verwendung einer allgegenwärtigen Sprache und der Definition begrenzter Kontexte kann Domain-driven Designs Teams dabei unterstützen, Software zu entwickeln, die eine Geschäftsdomäne wirklich widerspiegelt und den Bedürfnissen der Benutzer in dieser Domäne gerecht wird.

Domänengesteuertes Design erleichtert auch die Kommunikation über das Projekt, minimiert das Potenzial für Missverständnisse und reduziert den Nachbearbeitungsbedarf. Durch die Anwendung dieses Ansatzes konzentriert sich das Entwicklerteam auf die Bedürfnisse, die für die Domäne von zentraler Bedeutung sind, und vermeidet es, Zeit und Mühe für unnötige Dinge zu verschwenden.

Nachteile des Domain-Driven Designs

Eine große Herausforderung für kleine oder unerfahrene Entwicklungsteams und für Teams, die wenig oder keine Kenntnisse über die Geschäftsmodelle und -prozesse einer Organisation haben, besteht darin, dass Domain-driven Design umfassende Kenntnisse über eine Domäne erfordert. Domain-driven Design wird am häufigsten von Unternehmen auf Unternehmensebene eingesetzt, kann aber auch zu komplex und kostspielig sein, um es für einfachere Anwendungen zu implementieren.

Domain-driven Design eignet sich schlecht für hochtechnische Projekte und Projekte mit einfacher Geschäftslogik. Für erstere könnten die für die Implementierung von Domain-driven Design erforderliche Zeit und Ressourcen eine unüberwindbare Herausforderung darstellen, insbesondere für kleinere Organisationen oder Teams. Für letztere könnte die Implementierung von Domain-driven Design einfach zu viel des Guten sein. Der hohe Zeit- und Ressourcenaufwand steht möglicherweise in keinem Verhältnis zum Nutzen des Projekts, wenn dieser voraussichtlich minimal ist.

Ein weiterer Nachteil von Domain-driven Design besteht darin, dass die Einführung sowohl eine Änderung der Denkweise als auch der Unternehmenskultur erfordert. Für Entwickler, die es gewohnt sind, in einem vom Unternehmen getrennten Silo zu arbeiten, kann es schwierig sein, unter anderem über Geschäftsdomänen, Domänenmodelle und die Zusammenarbeit mit dem Unternehmen nachzudenken. Diese Schwierigkeiten können die Entwicklung und die Markteinführungszeit von Software verlangsamen.

Domain-driven Design und objektorientierte Programmierung

Domain-driven Design basiert auf objektorientierter Analyse und Design. In vielerlei Hinsicht kann Domain-driven Design als eine Möglichkeit betrachtet werden, objektorientierte Programmierung auf Geschäftsmodelle anzuwenden. Obwohl die beiden Ansätze nicht identisch sind, werden sie häufig zusammen eingesetzt. Die beiden Ansätze – Domain-driven Design mit seinem Schwerpunkt auf der Modellierung realer Konzepte und objektorientierte Programmierung, bei dem es um die Kapselung von Daten und Verhalten in Objekten geht – lassen sich gut miteinander kombinieren. Sie unterstützen Teams bei der Erstellung von Anwendungen für reale Geschäftsanforderungen und -modelle.

Domain-driven Design weist auch einige Überschneidungen mit anderen Entwicklungsphilosophien auf, wie zum Beispiel modellgetriebene Entwicklung (Model-driven Development, MDD), Event Sourcing und Command Query Responsibility Segregation (CQRS). Domain-driven Design kann insbesondere mit MDD verwendet werden, um bessere Domänenmodelle und Softwarecode zu erstellen, mit CQRS, um die Belange verschiedener Teile des Systems effektiv zu trennen, und mit Event Sourcing, um die Zustandsänderungen des Systems zu verwalten.