Nachtrag Einführung in Domain Driven Design

Ausgangssituation für das Design sind die erfassten Anwendungsfälle und das Fachmodell. Im Folgenden werde ich Ihnen knapp darlegen wie aus diesen beiden Modellen im ersten Schritt des Designs das Domain Modell mittels der Methoden Domain Driven Design erstellt werden kann als ein Schritt (Methode) für den Systementwurf.

Die Anwendungsfälle haben wir werden der Anforderungsanalyse erfasst als UML Use-Case Diagramm und als Tabellen oder Prosatext im Pflichtenheft oder Gesamtspezifikation spezifiziert und beschrieben. Das Use-Case Diagramm unten gibt einen Überblick über die Anwendungsfälle der Basar Anwendung.

Anschließend haben wir das Fachmodell werden der Anforderungsanalyse erfasst als UML Klassen Diagramm. Das Fachmodell beschreibt die fachlichen Klassen der Anwendung. Auf dem Modell operieren die erfassten Anwendungsfälle. Daher macht es Sinn das Modell aus dem Use-Case Diagramm abzuleiten. Das Klassen Diagramm unten gibt einen Überblick über die Klassen des Fachmodell der Basar Anwendung (Attribute sind im Modell nicht dargestellt).

Im Rahmen der Spezifikation der Anwendungsbausteine im Systementwurf in der Bausteinsicht haben wir die Methode Domain Driven Design kennengelernt zur Spezifikation der Geschäftlogik einer Fachanwendung als Domain Modell. Die Methode Domain Driven Design beschrieben von Eric Evans im Buch "Domain Driven Design – Trackling Complexity in Heart of Software" beschriebt die folgenden Model Element Typen.

Entities

"Many objects are not fundamentally defined by their attributes, but rather by a thread of continuity and identity" – Eric Evans. Eine Klasse vom Typ Entity beschreibt also ein Objekt das eine Identität hat z.B. Kunden.

Value Objects

"Many objects have no conceptual identity. These objects describe some characteristic of a thing" – Eric Evans. Ein Klasse vom Typ Value Object beschreibt ein Objekt das keine Identität hat. Also ein Objekt das kein eindeutigen technischen oder fachlichen Schlüssel besetzt der die Objektidentität beschreibt. Vielmehr beschreibt der Wert der Attribute bzw. Attribut die Identität des Objekts. Beispiel ein Objekt vom Typ Farbe ist dann gleich (hat die selbe Objektidentität) wenn es die gleichen RGB Werte z.B. für Schwarz hat.

Services

"Sometimes, it just isn’t a thing." – Eric Evans. Klassen vom Typ Service beinhalten operation die nicht direkt einer Klassen vom Typ Value Object oder Entity zugeordnet werden können.

Repositories

Klassen vom Typ Repository beinhalten Methoden zum speichern, laden und suchen von Enties oder Value Objects aus einer Datenquelle z.B. Datenbank oder Dateisystem.

Factories

Klassen vom Typ Factory dien dazu Objekte zu erzeugen und eine Trennung von Schnittstellen und Konkreten Implementierung zu ermöglichen. D.h. eine Service Klasse sollte natürlich nicht abhängig von der Implementierung der Repositories Klassen sein.

Domain Driven Design Beispiel

Nach dem wir einige der Grundbegriffe des Domain Driven Design beschrieben haben, sehen Sie unten ein Klassendiagramm für das Domain Modell der Basar Anwendung erstellt nach den Ideen des Domain Driven Design.

Da wir etwas in Verzug mit dem Stoff der Vorlesung sind, werden wir in der nächsten Vorlesung "Build Prozesse und Configuration Management" am 12.11.2010 das Thema Systementwurf und Domain Driven Design nochmals wiederholen und vertiefen.


Literatur:

• Domain-Driven Design - Eric J. Evans 2003 

Links:

• Domain Driven Design Sample Application - http://dddsample.sourceforge.net/