Definition „Domänen-getriebenes Design“ Was ist Domain-driven Design?

Domain-driven Design, kurz DDD, beschreibt Vorgehensweisen, die komplexe Software-Projekte transparenter für alle Beteiligten machen sollen. Gleichzeitig definiert es eine Reihe von Techniken und Elementen, mit denen ein optimiertes Domänenmodell erreicht werden soll.

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Windhoff Group

Windhoff Group

Ein komplexes Software-Projekt erfordert die aufwändige Koordination vieler Ressourcen. Fachexperten wissen exakt, welche Probleme es zu lösen gilt und Software-Entwickler wissen, mit welchen Mitteln das erreicht werden kann – doch die exakte Kommunikation zwischen diesen Personengruppen ist eine beträchtliche Herausforderung.

Domain-driven Design (DDD) ist ein Ansatz, der allen Beteiligten eine gemeinsame Plattform zur zweifelsfreien Kommunikation fachlicher Aspekte bieten soll. Neben wohldefinierten Vorgehensweisen schließt DDD eine einheitliche Sprache für Fachlichkeiten und ein Repertoire an Bauelementen und Techniken ein. Dadurch soll jeder Beteiligte stets genau wissen, wovon gesprochen wird und wie Vorgaben korrekt umzusetzen sind.

Der Aufwand für DDD ist sehr hoch, da alle Aspekte laufend standardisiert modelliert werden müssen. Doch für sehr komplexe und rentable Projekte lohnt der zusätzliche Einsatz, da Mehraufwand durch Missverständnisse und unklare Vorgaben stark reduziert werden kann.

Klar strukturieren mit Domänen

Beim DDD werden komplexe Zusammenhänge mithilfe klar abgegrenzter Domänen sauber modelliert. Sie bilden Fachlichkeit und Fachlogik des Anwendungsgebietes ab, meist die typischen Anforderungen und Zusammenhänge bestimmter geschäftlicher Vorgänge. Das Domänenmodell versucht, diese Anforderungen mit Konzepten aus der objektorientierten Entwicklung zu modellieren.

Einheitliche Sprache für alle

Für Domain-driven Design arbeiten Personen mit unterschiedlichsten Hintergründen zusammen. Damit die Kommunikation möglichst frei von Missverständnissen bleibt, ist ein einheitlicher Standard für die Beschreibung aller Komponenten des Projekts entscheidend: eine ubiquitäre Sprache. Es handelt sich um Formulierungen und Bezeichnungen, die von allen Beteiligten gleichermaßen verstanden wird. So kann von der Fachlichkeit bis zu einzelnen Methoden jeder Aspekt eindeutig ausgedrückt werden.

Die Sprache wird projektbegleitend weiterentwickelt, um die evolvierende Struktur des Systems zu unterstützen; auch Details wie die Änderung eines Klassennamens haben Einfluss. Wichtig: Die Sprache gilt immer nur im Kontext des jeweiligen Systems und kann in einem anderen Zusammenhang etwas völlig neues bedeuten.

Gut definierte Vorgehensweisen erleichtern komplexe Projekte

Damit die Integrität eines großen und komplexen Projekts gewahrt bleibt, gibt DDD bestimmte Vorgehensweisen vor. Je mehr Personen aus unterschiedlichen Teams und mit verschiedenen Hintergründen zusammenarbeiten sollen, desto wichtiger ist ein klarer Leitfaden.

Das Domänenmodell wandelt sich stetig mit wachsenden oder veränderten Anforderungen. Kontinuierliche Integration ist beim DDD dafür verantwortlich, diese Veränderungen ins Modell aufzunehmen und so die Einhaltung der Fachlichkeit zu gewähren. Die Vision der Fachlichkeit ist ein zentrales Element, das die Intentionen und Ziele der Kernfachlichkeit kurz beschreibt – und damit auch die Richtung, in die entwickelt werden soll.

Kernfachlichkeit

Die Kernfachlichkeit ist der Hauptnutzen des Domänenmodells, sozusagen der Kern der Anwendung. Es kann passieren, dass die Kernfachlichkeit sehr komplex und unübersichtlich wird. In solchen Fällen kann man mit einem separierten Kern modellieren. Hier wird die Kernfachlichkeit trotz enger Zusammenhänge mit anderen Modellelementen in ein eigenes Modul ausgelagert, um das System verständlicher und wartbarer zu gestalten.

Zudem gibt es noch das Konzept, einen geteilten Kern zu schaffen. Wenn die Kernfachlichkeit von vielen Teilen des Modells genutzt wird, welche selbst nur vage miteinander zusammenhängen, kann so eine gemeinsame Basis für alle Bereiche entwickelt werden. Schließlich gibt es noch Teile des Modells, die nicht zur Kernfachlichkeit gehören. Sie werden als generische Subfachlichkeiten in eigenen Modulen definiert und können daher gut ausgelagert oder durch Fremdsoftware abgedeckt werden.

Die Kontextgrenzen definieren, in welchem Teil des Modells welche Ressourcen und Ziele gelten. Für den nötigen Durchblick sorgt die Kontextübersicht. Sie dient als eine Art Karte, auf der alle Grenzen und Schnittstellen des Modells klar ersichtlich sind. Und die Beziehung zwischen den einzelnen, voneinander abhängigen Projektteams wird als Kunde-Lieferant-Beziehung abgebildet: Team A liefert die fachlichen Anforderungen, die Team B umsetzen soll.

Elemente des Domain-driven Design

Im DDD kann jede Domäne aus den folgenden Bestandteilen aufgebaut werden:

• Module: fachliche Bestandteile der Domäne.

• Entitäten: Objekte mit veränderlichen oder uneindeutigen Eigenschaften, die durch Ihre einzigartige Identität definiert sind (z. B. Personen).

• Wertobjekte: Objekte, die durch ihre Eigenschaften eindeutig definiert sind und typischerweise unveränderlich bleiben.

• Assoziationen: Beziehungen zwischen Objekten des Modells.

• Aggregate: Einheit aus Objekten und deren Beziehungen.

• Service-Objekte: fachlich relevante Funktionalitäten, die für mehrere Objekte der Domäne wichtig sind.

• Fachliche Ereignisse: Spezielle Objekte registrieren fachlich relevante Ereignisse und machen sie für andere Domänenteile sichtbar (z. B. Ereignisse in einem Aggregat anderen Aggregaten der Domäne mitteilen).

• Fabriken: Für komplexe Szenarien können verschiedene Erzeugungsmuster (meist factory oder builder patterns) herangezogen werden.

• Repositories: saubere Trennung von Domänen- und Datenschicht für die Abstrahierung des Systems.

(ID:45353292)