Domain-Driven Design

Domain-Driven Design (DDD) ist ein von Eric Evans in seinem Buch Domain-Driven Design geprägter Begriff für eine Anwendungsdomänen-getriebene Herangehensweise an das Design komplexer objektorientierter Software.^[1]

Domain-Driven Design ist nicht nur eine Technik oder Methode. Es ist viel mehr eine Denkweise und Priorisierung zur Steigerung der Produktivität von Softwareprojekten im Umfeld komplexer fachlicher Zusammenhänge.^[2] Domain-Driven Design basiert auf folgenden zwei Annahmen:

• Der Schwerpunkt des Softwaredesigns liegt auf der Fachlichkeit und der Fachlogik.
• Der Entwurf komplexer fachlicher Zusammenhänge sollte auf einem Domänenmodell basieren.

Domain-Driven Design ist an keinen bestimmten Softwareentwicklungsprozess gebunden, orientiert sich aber an Agiler Softwareentwicklung. Insbesondere setzt es Iterative Softwareentwicklung und eine enge Zusammenarbeit zwischen Entwicklern und Fachexperten voraus.^[3]

Beschreibung

Schichtenarchitektur

Domain-Driven Design ist eine Herangehensweise an die Modellierung komplexer Fachlichkeiten. Dabei wird eine Gliederung der Software durch eine Schichtenarchitektur vorausgesetzt. Das Hauptaugenmerk von Domain-Driven Design liegt dabei auf der Domänenschicht.

Ubiquitäre Sprache

Domain-Driven Design basiert auf einer Reihe von Konzepten, welche bei der Modellierung – aber auch anderen Tätigkeiten der Softwareentwicklung – berücksichtigt werden sollten. Das Hauptaugenmerk hierbei fällt auf die Einführung einer ubiquitären (allgemein verwendeten, allgegenwärtigen engl. ubiquitous) Sprache, welche in allen Bereichen der Softwareerstellung verwendet werden sollte. Eine Sprache für die Beschreibung der Business Requirements, der Modellelemente, der Klassen und Methoden etc. Sie wird definiert als:

„A language structured around the domain model and used by all team members to connect all the activities of the team with the software.“

„Eine Sprache, welche um das Domänenmodell strukturiert ist, und von allen Teammitgliedern verwendet wird um alle Aktivitäten des Teams mit der Software zu verknüpfen.“

– Eric Evans: Präsentationsunterlagen seines Vortrages vom 6. November 2007 auf der JAOO^[4]

Domain-Driven Design ist selbst unabhängig von Programmiersprachen, Tools und Frameworks. Dennoch gibt es eine Reihe von Tools und Frameworks, die Unterstützung für die Realisierung spezifischer DDD Patterns anbieten oder die Herangehensweise von DDD unterstützen.

Bestandteile des Domänenmodells

Domänenmodell

Domain-Driven Design unterscheidet die folgenden Bestandteile von Domänenmodellen :

Entitäten (engl. Entities bzw. Reference Objects)

Objekte des Modelles, welche nicht durch ihre Eigenschaften, sondern durch ihre Identität definiert werden. Beispielsweise wird eine Person meist als Entität abgebildet. Eine Person bleibt somit dieselbe Person, wenn sich ihre Eigenschaften ändern; und sie unterscheidet sich von einer anderen Person, auch wenn diese dieselben Eigenschaften hat. Entitäten werden oft mit Hilfe von eindeutigen Identifikatoren modelliert.

Wertobjekte (engl. Value Objects)

Objekte des Modelles, welche keine konzeptionelle Identität haben oder benötigen und somit allein durch ihre Eigenschaften definiert werden. Wertobjekte werden üblicherweise als unveränderliche Objekte (engl. immutable objects) modelliert, damit sind sie wiederverwendbar (vgl. Flyweight) und verteilbar.

Aggregate (engl. Aggregates)

Aggregate sind Zusammenfassungen von Entitäten und Wertobjekten und deren Assoziationen untereinander zu einer gemeinsamen transaktionalen Einheit. Aggregate definieren genau eine Entität als einzigen Zugriff auf das gesamte Aggregat. Alle anderen Entitäten und Wertobjekte dürfen von außerhalb nicht statisch referenziert werden. Damit wird garantiert, dass alle Invarianten des Aggregats und der einzelnen Bestandteile des Aggregats sichergestellt werden können.

Assoziationen (engl. Associations)

Assoziationen sind, wie bei UML definiert, Beziehungen zwischen zwei oder mehr Objekten des Domänenmodells. Hier werden allerdings nicht nur statische, durch Referenzen definierte Beziehungen betrachtet, sondern auch dynamische Beziehungen, die beispielsweise erst durch die Abarbeitung von SQL-Queries entstehen.

Serviceobjekte (engl. Services)

Bei Domain-Driven Design werden Funktionalitäten, welche nicht konzeptionell zu einem Objekt des Modelles gehören, als eigenständige Serviceobjekte modelliert. Serviceobjekte sind üblicherweise zustandslose (eng. stateless) Klassen ohne Assoziationen mit Methoden, die den angebotenen Funktionalitäten entsprechen. Diese Methoden bekommen die Wertobjekte und Entitäten übergeben, die zur Abarbeitung der Funktionalität notwendig sind.

Fachliche Ereignisse (engl. Domain Events)

Fachliche Ereignisse sind Objekte, welche fachliche Ereignisse beschreiben, die ein oder mehrere Aktionen oder Änderungen in den Fachobjekten bewirken. Damit wird die Modellierung komplexer, sich unter Umständen auch dynamisch ändernder fachlicher Aktionen vereinfacht. Fachliche Ereignisse ermöglichen auch die Modellierung verteilter Systeme. Die einzelnen Subsysteme kommunizieren ausschließlich über fachliche Ereignisse, damit werden sie stark entkoppelt und das gesamte System somit wartbarer und skalierbarer.^[5]

Module (engl. Modules bzw. Packages)

Module teilen das Domänenmodell in fachliche (nicht technische) Bestandteile. Sie sind gekennzeichnet durch starke innere Kohäsion und geringe Kopplung zwischen den Modulen.

Außerdem kennt das Domain-Driven Design noch zwei weitere Bestandteile der Domänenschicht – Factories und Repositories. Diese kommen zwar selbst nicht aus der Fachlichkeit, sind aber dennoch Bestandteil des Domänenmodells, da sie für den Lebenszyklus der Fachobjekte wichtige Funktionalität bereitstellen.

Fabriken (engl. Factories)

Fabriken dienen dazu, die Erzeugung von Fachobjekten in spezielle Fabrik-Objekte auszulagern. Dies ist dann sinnvoll, wenn entweder die Erzeugung komplex ist (und beispielsweise Assoziationen benötigt, die das Fachobjekt selbst nicht mehr benötigt) oder die spezifische Erzeugung der Fachobjekte zur Laufzeit ausgetauscht werden können soll. Fabriken werden üblicherweise durch erzeugende Entwurfsmuster wie Abstrakte Fabrik, Fabrikmethode oder Erbauer umgesetzt.

Repositories

Repositories abstrahieren die Persistierung von Fachobjekten. Damit werden die technische Infrastruktur sowie die Zugriffsmechanismen auf diese von der Domänenschicht getrennt. Alle Fachobjekte, auf die ein globaler Zugriff benötigt wird, bekommen ein Repository Objekt, welches nach außen die verwendeten Persistenztechnologien abkapselt. Üblicherweise werden Repositories mittels der Entwurfsmuster Data Access Objects, Query Objects oder Metadata Mapping Layers umgesetzt.

Die Namen der basierend auf diesen Typen entstehenden Objekten der Domänenschicht sind Teile der ubiquitären Sprache und sollten entsprechend benannt werden. Eine Änderung des Namens eines Fachobjektes durch Refactoring entspricht somit einer Änderung der Fachlichkeit der Applikation.

Weitere Techniken

Domain-Driven Design beschreibt und empfiehlt eine Reihe weiterer Techniken und Herangehensweisen für die Umsetzung des Domänenmodells:

Architekturtechniken

• Evolvierende Struktur (engl. evolving order) - geht davon aus, dass große Strukturen im Domain Layer idealerweise erst mit der Zeit entstehen beziehungsweise sich über die Zeit entwickeln. Große Strukturen sollten möglichst einfach und mit möglichst wenigen Ausnahmen umgesetzt sein.
• Systemmetapher (engl. system metaphor) - ist ein Konzept aus Extreme Programming, welche die Kommunikation zwischen allen Beteiligten erleichtert, indem es das System mittels einer Metapher, einer inhaltlich ähnlichen, für alle Seiten verständlichen Alltagsgeschichte beschreibt. Diese sollte möglichst gut passen und zur Stärkung der ubiquitären Sprache verwendet werden.
• Verantwortlichkeitsschichten (engl. responsibility layers) - ist die Aufteilung des Domänenmodells in Schichten gemäß Verantwortlichkeiten. Domain-Driven Design schlägt folgende Schichten vor: Entscheidungsschicht, Regelschicht, Zusagen, Arbeitsabläufe, Potential.
• Wissenslevel (engl. knowledge level) - beschreibt das explizite Wissen über das Domänenmodell. Es ist in Situationen notwendig, wo die Abhängigkeiten und Rollen zwischen den Entitäten situationsbedingt variieren. Das Wissenslevel sollte diese Abhängigkeiten und Rollen von außen anpassbar enthalten, damit das Domänenmodell weiterhin konkret und ohne unnötige Abhängigkeiten bleiben kann.
• Einsteckbare Komponentenframeworks (engl. pluggable component framework) - ist die Überlegung verschiedene Systeme über ein Komponentenframework miteinander zu verbinden.

Designtechniken

• Intentionen beschreibende Schnittstellen (engl. intention-revealing interfaces) - bezeichnen Schnittstellen von Klassen und Komponenten, welche es den Entwicklern ermöglichen ebendiese zu verwenden, ohne deren Sourcecode studieren zu müssen. Damit wird sowohl bei Verwendung als auch bei der Wartung dieser Klassen und Komponenten sichergestellt, dass diese gemäß deren Intentionen erfolgt.
• Seiteneffektfreie Funktionen (engl. side-effect-free functions) - sind Methoden, welche keinen Einfluss auf den Zustand eines Moduls haben. Diese sind einfacher zu testen und sollten somit bevorzugt werden. Sie sollten daher den Großteil der Applikationslogik enthalten. Den Zustand verändernde Methoden - sogenannte command Methoden - sollten von ihnen getrennt werden, möglichst einfach gehalten werden und keine Domain Informationen retournieren.
• Assertions - dienen im Domain-Driven Design dazu, Nebeneffekte von aufgerufenen Methoden sichtbar zu machen, ohne deren Sourcecode studieren zu müssen. Diese, dem design by contract nahe Vorgangsweise führt dazu, dass Entwickler die Auswirkungen der verwendeten Methoden verstehen können, und somit erst Datenkapselung richtig eingesetzt werden kann.
• Eigenständige Klassen (engl. standalone classes) - sind Klassen, welche keine expliziten oder impliziten Abhängigkeiten zu anderen Klassen haben. Sie sind einfacher zu verstehen und sollten somit durch Eliminierung aller unnötigen Abhängigkeiten angestrebt werden.
• Konzeptionelle Konturen (engl. conceptual contours) - beschreibt die Konzepte, welche der Struktur eines Designs zugrunde liegen. Diese sollten durch sukzessive Refactorings an die stabilen Aspekte der Fachlichkeit angepasst werden. Damit steigt die Wahrscheinlichkeit, dass zukünftige Änderungen mit dem bestehenden Design leichter umgesetzt werden können.
• Funktionsabschlüsse (engl. closure of operations) - sind beim Domain-Driven Design Methoden, deren Rückgabetyp derselbe ist, wie derjenige ihrer Argumente oder der in der Methode verwendeten Attribute. Diese Methoden erweitern zwar die Möglichkeiten einer Klasse, führen aber keine Abhängigkeiten auf andere Konzepte ein. Sie sind daher gegenüber Methoden, deren Rückgabe andere Typen einführen, vorzuziehen.

Vorgehensweisen

Darüber hinaus definiert Domain-Driven Design eine Reihe von Vorgehensweisen, welche bei der Umsetzung von Domain-Driven Design hilfreich sein sollen. Die Grafik rechts zeigt die Abhängigkeiten zwischen diesen und anderen Elementen von Domain-Driven Design.

Vorgehensweisen

• Kontextübersicht (engl. context map) - dient einer gesamthaften Übersicht über alle Modelle, deren Grenzen und Schnittstellen. Dadurch wachsen die Kontexte nicht in Bereiche anderer Kontexte und die Kommunikation zwischen den Kontexten läuft über wohldefinierte Schnittstellen.
• Kontextgrenzen (engl. bounded context) - beschreiben die Grenzen jedes Kontexts in vielfältiger Hinsicht wie beispielsweise Teamzuordnung, Verwendungszweck, dahinter liegende Datenbankschemata. Damit wird klar, wo ein Kontext seine Gültigkeit verliert und potentiell ein anderer Kontext seinen Platz einnimmt.
• Kontinuierliche Integration (engl. continuous integration) - dient beim Domain-Driven Design dazu, dass alle Veränderungen eines Domänenmodells laufend miteinander integriert werden und gegen bestehende Fachlichkeit automatisiert getestet werden.
• Vision der Fachlichkeit (engl. domain vision statement)
• Kernfachlichkeit (engl. core domain)
• Generische Sub-Fachlichkeiten (engl. generic subdomains)
• (engl. segregated core)
• Deklarativer Stil (engl. declarative style)

Vergleich zu anderen Technologien

Objektorientierte Analyse und Design

Obwohl sich DDD theoretisch nicht auf objektorientierte Konzepte beschränkt, wird DDD in der Praxis hauptsächlich für objektorientierte Analyse und Design eingesetzt. Viele der Konzepte von DDD basieren auf Paradigmen der objektorientierten Softwareentwicklung. DDD kann somit als Methodik für objektorientierte Analyse und Design angesehen werden.

Modellgetriebene Softwareentwicklung und Model Driven Architecture (MDA)

DDD ist zwar mit Modellgetriebener Softwareentwicklung kompatibel, hat allerdings unterschiedliche Intentionen. Modellgetriebene Softwareentwicklung befasst sich mehr mit den Techniken, wie Modelle in unterschiedlichen Softwareplattformen umgesetzt werden können, während DDD sich hauptsächlich damit befasst, wie man zu besseren Domainmodellen kommt. Im Gegensatz zu Modellgetriebener Softwareentwicklung setzt DDD stark auf ein kontinuierlich evolvierendes Modell, welches durch laufendes Refactoring verbessert wird.

Plain Old Java Objects (POJOs) und Plain Old CLR Objects (POCOs)

POJOs und POCOs sind technische Konzepte aus Java und .NET. Sie basieren allerdings auf der in DDD ebenfalls propagierten Ansicht, dass Domainobjekte ausschließlich Anforderungen der Fachlichkeiten des Domänenmodells und nicht technologiespezifische Anforderungen implementieren sollen.

Naked Objects

Naked Objects ist ein Architekturmuster, welches wie DDD davon ausgeht, dass die gesamte Fachlogik in Fachobjekten abzubilden ist. Weiters propagiert das Naked Objects Architekturmuster, dass die Benutzerschnittstelle eine direkte Abbildung der Fachobjekte sei und somit 100% aus den Fachobjekten generiert werden sollte – eine Forderung, die DDD nicht stellt.^[6]

Objektorientierte Persistenzmechanismen

Objektorientierte Persistenzmechanismen wie Objektrelationale Abbildung oder Objektdatenbanken beschäftigen sich mit dem Ersatz der Datenzugriffsschicht unter den Fachobjekten. Sie sind somit eine synergetische Ergänzung für Domain-Driven Design, da sich damit die Architektur noch stärker auf die Fachobjekte zentriert.

Data Context Interaction (DCI)

Data Context Interaction ist ein Architekturmuster welches die Bestandteile von Fachmodellen des Domain-Driven Designs (Entitäten, Wertobjekte, Aggregate, Serviceobjekte und Fachliche Ereignisse) ergänzen kann, beziehungsweise durch diese ergänzt werden kann. So können die Datenobjekte von DCI durch die Entitäten, Wertobjekte und Aggregate von DDD verfeinert werden, Kontext Objekte wiederum lassen sich durch Serviceobjekte und Fachliche Ereignisse abbilden. Die Rollen der Interaktionen von DCI jedoch erweitern wiederum die Bestandteile des Domain-Driven Designs. Beide Technologien können also durchaus als kompatibel und einander ergänzend betrachtet werden.

Domänenspezifische Sprache (DSL)

Eine domänenspezifische Sprache (engl. domain-specific language, DSL) ist eine formale Sprache, die speziell für ein bestimmtes Problemfeld (die Domäne) entworfen und implementiert wird. DDD ist selbst keine und benötigt auch keine DSL um funktionieren zu können. DDD kann allerdings verwendet werden um eine DSL zu definieren.

Aspektorientierte Programmierung (AOP)

AOP ist eine Technologie, die es im DDD ermöglicht, bestimmte, sonst üblicherweise tief verwobene technische Aspekte (wie Logging, Security, Transaktionsmanagement) vom Domänenmodell zu trennen. Damit wird es einfach, dem von DDD gestellten Anspruch der vollständigen Trennung des Domänenmodells und der Businesslogik vom Rest der Applikation gerecht zu werden.

Literatur

• Eric Evans: Domain-Driven Design. Tackling Complexity in the Heart of Software. Addison Wesley, 30. August 2003, ISBN 978-0321125217 (http://www.domaindrivendesign.org/).
• Dan Haywood: Domain-Driven Design using Naked Objects. Pragmatic Programmers, 2. Dezember 2009, ISBN 978-1934356449 (Domain-Driven Design using Naked Objects).
• Floyd Marinescu, Abel Avram: Domain-Driven Design Quickly. Lulu Press, 8. Juni 2006, ISBN 978-1411609259 (InfoQ: Domain Driven Design Quickly).
• Jimmy Nilsson: Applying Domain-Driven Design and Patterns. With Examples in C# and .NET. 18. Mai 2006, ISBN 0-321-26820-2.

Weblinks

• Putting the Model to Work und Strategic Design, 2-teiliger Vortrag von Eric Evans auf der JAOO vom 6. November 2007
• Domain Driven Design, Interview mit Jimmy Nilsson
• Eric Evans: What I've learned about DDD since the book, Vortrag von Eric Evans, ursprünglich präsentiert auf der QCon London 2009, aufgenommen bei DDD-NYC SIG.
• Domain-Driven Design Community
• Dan Haywood: An Introduction to Domain Driven Design. Methods & Tools, Winter 2009, abgerufen am 12. Juli 2010 (englisch). 

Einzelnachweise

1. ↑ Eric Evans; Addison Wesley (Hrsg.): Domain-Driven Design. Tackling Complexity in the Heart of Software. Addison Wesley, 30. August 2003, ISBN 978-0321125217 (http://www.domaindrivendesign.org/).
2. ↑ Definition von DDD lt. domaindrivendesign.org
3. ↑ Eric Evans; Addison Wesley (Hrsg.): Domain-Driven Design. Tackling Complexity in the Heart of Software. Addison Wesley, 30. August 2003, ISBN 978-0321125217, S. xxii (http://www.domaindrivendesign.org/).
4. ↑ Präsentation auf der JAOO vom 6. November 2007 von Eric Evans, Präsentation auf InfoQ
5. ↑ Eric Evans: What I've learned about DDD since the book. Domain Language, Inc., Mai 2009, abgerufen am 23. Oktober 2010 (Video, englisch, Diskussion der Domain Events von 13:00 bis 28:05. Präsentation aufgenommen bei DDD-NYC SIG, ursprünglich präsentiert auf der QCon London 2009.). 
6. ↑ Dan Haywood; Pragmatic Programmers (Hrsg.): Domain-Driven Design using Naked Objects. Pragmatic Programmers, 2. Dezember 2009, ISBN 978-1934356449 (Domain-Driven Design using Naked Objects).