Domain-Driven Design

Was ist DDD?

Domain Driven Design ist ein von Eric Evans geprägter Begriff für eine Anwendungsdomänen-getriebene Herangehensweise an das

Design komplexer objektorientierter Software.

Geistige Väter des DDD

• Jimmy Nilsson

• Eric Evans

• Martin Fowler

Was ist eine Domäne?

• im Softwarekontext eine Problemdomäne

• ein abgrenzbares Problemfeld oder einen bestimmten Einsatzbereich für Software

• im Folgenden steht Fachdomäne für die Probleme des Kunden und Anwendungsdomäne für die Represäntation der Fachdomäne auf Seite des Dienstleisters

Was ist ein Modell?

• ein Model ist eine auf bestimmte Zwecke ausgerichtete vereinfachende Beschreibung der Wirklichkeit

• zum Beispiel eine Bauzeichnung

Was bietet mir DDD?

• es vereinheitlicht das Verständnis der Fachdomäne zwischen allen Projektbeteiligten

• es hält die Differenz zwischen der Fachdomäne und der Anwendungsdomäne möglichst klein

• es verhindert ein anemisches Anwendungsmodell(ein Modell ohne Fachlogik)

• es teilt die Komplexität der Fachdomäne in verständliche Teile

Was bietet mir DDD?

• es ermöglicht das iterative Analysieren der Fachdomäne

• es erlaubt die iterative Entwicklung des Anwendungsmodells

• es trennt die Software in gut wartbare Teile mit wenig Seiteneffekten

• es erleichtert neuen Projektteilnehmern den Einstieg

Und wie geht das?

• Kunde (Domänenexperte) und Dienstleister (PM & Entwickler) kartografieren gemeinsam die Fachdomäne

• Bestandteile werden erkannt und benannt

• ein kontinuierlicher Prozess (iterativ/agil)

• Ergebnis ist das Anwendungsmodell, dasdie Anwendungsdomäne repräsentiert

Und wie geht das?

• die Namen der Bestandteile werden Teil der „ubiquitous language“(allgegenwärtige und gemeinsame Sprache)

• diese Sprache wird von allen Projektbeteiligten gesprochen und im Modell verwendet

Wo platziere ich das Modellin meiner Anwedung?

User Interface

Anwendung

Modell

Infrastruktur

Bausteine des DDD

• Entities

• Value Objects

• Aggregates

• Relations

• Repositories

• Factories

• Services

• [Modules]

• [Domain Events]

Domain Objects

• repräsentieren Objekte der Fachdomäne

• beinhalten die Fachlogik

• werden durch…

• eine einzigartige Identität

• oder ihre Eigenenschaften

• …in einer Menge von Objekten gleichen Typs identifiziert

Domain Objects

Value Objects

• identifizierbar durch ihre Eigenschaften

• z.B. Adresse eines Geschäfts

Entities

• identifizierbar durch ihre Identität

• z.B. das Geschäft selbst

Relations

• sind die Beziehungen zwischen zwei oder mehreren Domain Objects

Aggregate

• sind Zusammenfassungen von Entities, Value Objects und deren Relations untereinander

• sind selbst ein Entity

• der Zugriff auf die beinhalteten Objekte erfolgt ausschließlich über das Aggregate

Domain Services

• Prozesse, die nicht direkt einem Domain Object zuzuordnen sind

• steuert Interaktion zwischen Verschiedenen Domain Objects

• z.B. Überweisungen zwischen zwei Bankkonten zweier Kunden

Repositories

• speichern und finden Entities

• abstrahieren die Persistenz (das Speichern und Wiederherstellen von Objekten)

• sind die Schnittstelle zur Infrastruktur

Factories

• erzeugen Domain Objects wenn die Erzeugung für das Domain Object selbst zu komplex ist

• werden benötigt wenn z.B. Relations bei der Erzeugung aufgebaut werden müssen

Aber wie halte ich mein Modell „sauber“?

• besonders wenn mehrere Entwickler in der Anwendungsdomäne arbeiten ist das schwierig

• DDD bietet dafür einige Verfahrensweisen

• Bounded Context

• Context Map

• Core Domain

• Shared Kernel

Bounded Context

• beschreibt die Grenzen des Kontexts einer Anwendungsdomäne hinsichtlich

• Verwendungszweck

• Teamzuordnung

• Implementierungsdetails

• Verantwortlichkeiten werden klar abgebildet

Context Map

• beschreibt in Vogelperspektive die Grenzen und Schnittstellen der Bounded Contexts zueinander

• verhindert das Überschreiten von Grenzen zwischen Bounded Contexts

• beschreibt die Kommunikation zwischen Bounded Contexts über deren Schnittstellen

Core Domain

• ist der wertvollste Teil des Fachmodells

• muss besonders „sauber“ bleiben

• andere Teile des Modells reichern diesen Teil in seiner Tätigkeit nur an

• sollte von den besten Entwicklern im Team betreut werden

Shared Kernel

• ist die gemeinsame Schnittmenge zwischen Bounded Contexts

• wird in enger Abstimmung von den Teams der Bounded Contexts gemeinsam weiterentwickelt

Fragen?