Domain Driven Design

Dieser Artikel stammt aus unserem Blog, der nicht mehr betreut wird. Für Neuigkeiten zu oose und interessante Inhalte zu unseren Themen, folgt uns gerne auf LinkedIn.

Vaughn Vernon hat kürzlich sein Buch "Implementing Domain Driven Design" (DDD) bei Addison-Wesley veröffentlicht, welches ich ohne jetzt weiter auf den Inhalt einzugehen, schonmal uneingeschränkt empfehlen möchte. Domain Driven Design lebt davon, aus den Fundus einer definierten Mustersprache zu schöpfen, und für die eigene zu betrachtende Domäne ebenso eine eindeutige Sprache zu erzeugen.

Für ehemalige und künftige Besucher unseres Seminars "Objektorientierte Analyse und Design" möchte ich einfach mal eine Brücke zwischen diesen beiden Vokabelwelten schlagen, um ihre Gemeinsamkeiten zu betonen. Dabei gibt es natürlich Unterschiede, die ich hier nicht weiter hervorhebe, aber genau deswegen ist die Lektüre der Bücher um DDD so empfehlenswert.

Wenn in der Welt des DDD zunächst einmal probiert wird, die zu betrachtende Welt auf einen wichtigen und relevanten Teilbereich einzuschränken, den sogenannten Bounded Context, so entspricht dies in unserer Sprache der Diskussion um die Systemidee und den Systemkontext. Über Entities und Value Objects sprechen wir in nahezu identischer Weise, in dem Sinne, dass sie unser Domänenmodell/Fachklassenmodell abbilden. Im bei uns gewählten Architekturmodell spielt es eine zentrale Rolle, wo eigentlich genau Geschäftslogik abgebildet wird, und was Geschäftslogik eigentlich ist. Diese Diskussion spiegelt sich im Rahmen von DDD in der Rolle von Services wieder, die bei uns Controller heissen. Ebenso betrachtet wird in beiden Welten das "blutleere" Domänenmodell.

Am wichtigsten im DDD ist vielleicht die Verwendung einer eindeutigen Sprache, der Ubiquitous Language um zwischen Domänenexperten und Entwicklern zu kommunizieren. Auch auf dieses Konzept achten wir sehr stark, wenn wir unsere Analysevokabeln entwickeln (Mitglied! Nicht Kunde, Person, ...) und unsere Analyseinstrumente einsetzen (Was ist eigentlich ein Systemanwendungsfall, Aktivität, Aktion, Fachklasse? - wie sind diese Dinge definiert und abgegrenzt).

Auch die Rolle von Factories wird von Vaughn Vernon sehr gut definiert:

Shift the responsibility for creating instances of complex objects and aggregates to a separate object, which may itself have no responsibility in the domain model but is still part of the domain design.

Wohlgemerkt: dieser Vergleich war nun sehr oberflächlich, und der Teufel steckt oftmals im Detail. Und dennoch: was wir Ihnen in unseren Seminaren immer wieder mitgeben wollen, ist es mit einer Bestimmtheit und Eindeutigkeit über "Dinge" zu sprechen - gewiss ein Kernanliegen zum Ansatz des Domain Driven Design.