Domain-Driven Design

24
Domain-Driven Design

Transcript of Domain-Driven Design

Page 1: Domain-Driven Design

Domain-Driven Design

Page 2: 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.

Page 3: Domain-Driven Design

Geistige Väter des DDD

• Jimmy Nilsson

• Eric Evans

• Martin Fowler

Page 4: Domain-Driven Design

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

Page 5: Domain-Driven Design

Was ist ein Modell?

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

• zum Beispiel eine Bauzeichnung

Page 6: Domain-Driven Design

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

Page 7: Domain-Driven Design

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

Page 8: Domain-Driven Design

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

Page 9: Domain-Driven Design

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

Page 10: Domain-Driven Design

Wo platziere ich das Modellin meiner Anwedung?

User Interface

Anwendung

Modell

Infrastruktur

Page 11: Domain-Driven Design

Bausteine des DDD

• Entities

• Value Objects

• Aggregates

• Relations

• Repositories

• Factories

• Services

• [Modules]

• [Domain Events]

Page 12: Domain-Driven Design

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

Page 13: Domain-Driven Design

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

Page 14: Domain-Driven Design

Relations

• sind die Beziehungen zwischen zwei oder mehreren Domain Objects

Page 15: Domain-Driven Design

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

Page 16: Domain-Driven Design

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

Page 17: Domain-Driven Design

Repositories

• speichern und finden Entities

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

• sind die Schnittstelle zur Infrastruktur

Page 18: Domain-Driven Design

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

Page 19: Domain-Driven Design

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

Page 20: Domain-Driven Design

Bounded Context

• beschreibt die Grenzen des Kontexts einer Anwendungsdomäne hinsichtlich

• Verwendungszweck

• Teamzuordnung

• Implementierungsdetails

• Verantwortlichkeiten werden klar abgebildet

Page 21: Domain-Driven Design

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

Page 22: Domain-Driven Design

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

Page 23: Domain-Driven Design

Shared Kernel

• ist die gemeinsame Schnittmenge zwischen Bounded Contexts

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

Page 24: Domain-Driven Design

Fragen?