Domain-Driven Design

1,213 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,213
On SlideShare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Domain-Driven Design

  1. 1. Domain-Driven Design
  2. 2. 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.
  3. 3. Geistige Väter des DDD • • • Jimmy Nilsson Eric Evans Martin Fowler
  4. 4. 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
  5. 5. Was ist ein Modell? • ein Model ist eine auf bestimmte Zwecke ausgerichtete vereinfachende Beschreibung der Wirklichkeit • zum Beispiel eine Bauzeichnung
  6. 6. 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
  7. 7. 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
  8. 8. 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, das die Anwendungsdomäne repräsentiert
  9. 9. 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
  10. 10. Wo platziere ich das Modell in meiner Anwedung? User Interface Anwendung Modell Infrastruktur
  11. 11. Bausteine des DDD • Entities • Value Objects • Aggregates • Relations • Repositories • Factories • Services • [Modules] • [Domain Events]
  12. 12. 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
  13. 13. 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
  14. 14. Relations • sind die Beziehungen zwischen zwei oder mehreren Domain Objects
  15. 15. 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
  16. 16. 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
  17. 17. Repositories • speichern und finden Entities • abstrahieren die Persistenz (das Speichern und Wiederherstellen von Objekten) • sind die Schnittstelle zur Infrastruktur
  18. 18. 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
  19. 19. 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
  20. 20. Bounded Context • beschreibt die Grenzen des Kontexts einer Anwendungsdomäne hinsichtlich • Verwendungszweck • Teamzuordnung • Implementierungsdetails • Verantwortlichkeiten werden klar abgebildet
  21. 21. 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
  22. 22. 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
  23. 23. Shared Kernel • ist die gemeinsame Schnittmenge zwischen Bounded Contexts • wird in enger Abstimmung von den Teams der Bounded Contexts gemeinsam weiterentwickelt
  24. 24. Fragen?

×