adesso Blog

Menschen, die zusammen an einem Tisch sitzen

Von zentraler Bedeutung für die Softwareentwicklung ist die Modellierung der Fachdomäne. Domain Driven Design, kurz DDD, ist eine Sammlung von Werkzeugen, um die Modellierung der Domäne zu unterstützen. DDD wurde erstmalig durch Eric Evans in seinem Buch Domain Driven Design - Tackling Complexity in the Heart of Software beschrieben.

In dem adesso Blog Herausforderungen in der Domänenmodellierung werden einige Herausforderungen in der Domänenmodellierung nach DDD beschrieben. Es wird die Notwendigkeit für ein gemeinsames Domänenverständnis innerhalb der Projektteams aufgezeigt. Zudem wird auf die Möglichkeit einer hohen Domänenkomplexität hingewiesen. In der Detailmodellierung ist die Modellierung der Domänenelemente notwendig. Weiterhin ist das Gestalten der Abhängigkeiten zwischen den zuvor ermittelten Domänenelementen zu betrachten.

In DDD stehen Werkzeuge zur Verfügung, diese Herausforderungen zu adressieren. Dieser Artikel beschreibt diese Werkzeuge, sowie deren Anwendung, anhand eines fiktiven Beispiels. Es wird die Entwicklung einer Software zur Verwaltung und Abrechnung von Reisebuchungen betrachtet.

Ubiquitous Language und Bounded Context

Die Herausforderung für ein gemeinsames Domänenverständnis können wir in DDD durch Anwendung einer gemeinsamen Domänensprache adressieren. Diese wird als Ubiquitous Language, also allgegenwärtige Sprache, bezeichnet. Sie beinhaltet die in der Domäne wichtigen Begriffe und Funktionen, die in einem begrenzten fachlichen Kontext zu modellieren sind. In DDD wird für den Kontext der Begriff Bounded Context verwendet. Die Begriffe und Funktionen können wir unter den Teams bekannt machen, die an dem Projekt beteiligt sind. Dies sind insbesondere die Teams aus der Entwicklung, die das fachliche Modell erstellen, und die Teams aus der Fachabteilung mit Domänenexpertise, die zur Anforderungsanalyse zur Verfügung stehen. Das gemeinsame Domänenverständnis wird somit durch Anwendung der gemeinsamen Domänensprache erreicht.

In dem Beispiel der Reisebuchungen sind mindestens die Begriffe Reisebuchung, Rechnung, Kunde und Reise-Betrieb relevant. Wir betrachten zunächst den Begriff Reisebuchung. Sowohl die Teams aus der Entwicklung als auch aus der Fachabteilung müssen ein gemeinsames Verständnis für die fachlichen Eigenschaften einer Reisebuchung haben. In unserem einfachen Beispiel beinhaltet eine Reisebuchung ein Startdatum und Enddatum, ein Startpunkt und Endpunkt, sowie optionale Zwischenstationen. Die weiteren Begriffe und die sie betreffenden Funktionen müssen wir ebenfalls definieren und modellieren.

Der Bounded Context legt nun für uns fest, welche fachlichen Funktionen in einem Kontext abgedeckt sind. In unserem Beispiel gibt es die Anforderungen Reisebuchungen und Rechnungen zu verwalten. Eine Mitarbeiterin oder ein Mitarbeiter des Fachbereichs möchte eine Reisebuchung erstellen, die von einem Kunden in Auftrag gegeben wird. Weiterhin ist mindestens ein Reise-Betrieb zur Durchführung der Reise festzulegen. Hat nun die Rechnung in diesem Aufgabenfeld keine Relevanz, ist die Rechnung nicht Teil des Kontexts zur Erstellung einer Reisebuchung.

Die Ubiquitous Language kann durch wiederkehrende Meetings zwischen den Teams aus der Fachabteilung und der Entwicklung aufgebaut werden. In den Meetings stellen die Mitarbeiterinnen und Mitarbeiter der Fachabteilung die Anforderungen an das System durch Beschreibung der eigenen Aufgaben vor. Die Entwicklerinnen und Entwickler greifen die in den Anforderungen erwähnten fachlichen Begriffe und Funktionen auf und teilen ihr Verständnis hiervon durch Modellierung der Domäne mit. Der Fachbereich überprüft und korrigiert das von den Entwicklerinnen und Entwicklern aufgenommene Verständnis. Die Korrekturen können sich auf die fachliche Bedeutung der aufgegriffenen Begriffe und Funktionen beziehen. Es kann aber auch zur Ergänzung neuer Begriffe und Funktionen kommen. So kann sich im Verlauf der Gespräche unseres Beispiels herausstellen, dass ein Verkehrsmittel zu Planungszwecken relevant sein kann.

Initiales Domänenmodell

Die Effekte durch Anwendung der Ubiquitous Language sind nach DDD ein erhöhtes Verständnis der Entwicklerinnen und Entwickler für die Domäne. Dies wiederum reduziert das Risiko für Missverständnisse während der Entwicklung. Demnach wird der Ubiquitous Language eine zentrale Rolle bei der Entwicklung einer Software zugeschrieben.

Subdomains

Ab einer gewissen Größe und Komplexität der Domäne wird die Modellierung dieser zunehmend aufwändig. Für diesen Fall wird in DDD die Unterteilung in einzelne Teilbereiche empfohlen, die als Subdomains bezeichnet werden. Die Unterteilung wird notwendig, wenn unterschiedliche Elemente der Ubiquitous Language nicht in einen gemeinsamen Bounded Context fallen. Die Herausforderung besteht dabei nicht nur in der Erkennung einer Unterteilung in Teilbereiche, sondern insbesondere in der Festlegung dieser.

In unserem Beispiel können wir zunächst die Subdomain Verwaltung Reisebuchung definieren. Wie wir weiterhin gesehen haben, ist unter anderem der Begriff Rechnung relevant. Allerdings ist in den Gesprächen mit den Teams aus der Fachabteilung erkennbar, dass die Rechnung bei der Zusammenstellung einer Reisebuchung keine direkte Rolle spielt. Die Rechnung ist in diesem einfachen Beispiel viel mehr eine Folge der Zusammenstellung einer Reisebuchung. Da die Rechnung aber weiterhin Relevanz hat, ist es sinnvoll, diese in eine eigene Subdomain Abrechnung mit einem entsprechenden Bounded Context zu legen. Die Definition des Bounded Context legt somit den Umfang der Subdomains Verwaltung Reisebuchung und Abrechnung fest. Dies entspricht der geforderten Festlegung der Unterteilung von fachlichen Teilbereichen.

DDD bietet neben der Adressierung einer sinnvollen Unterteilung auch ein Werkzeug zur Kommunikation der Subdomains untereinander. Hierzu werden Schnittstellen einer Subdomain definiert, welche von einer anderen Subdomain verwendet werden. In DDD wurde für die Festlegung dieser Schnittstellen der Begriff Context Map eingeführt.

Aus den Gesprächen mit den Teams aus der Fachabteilung wissen wir, dass die Erstellung einer Reisebuchung zur Erstellung einer Rechnung führt. Wir benötigen somit eine Schnittstelle in der Subdomain Abrechnung, welche Daten der Reisebuchung entgegen nimmt, die für die Erstellung der Rechnung benötigt werden.

Subdomains und Context Map

Die Unterteilung der Domäne in Subdomains reduziert die Komplexität innerhalb eines Kontexts, da nicht direkt im Kontext beteiligte Domänenelemente ausgeklammert werden.

Entitites und Values

Die Domänenelemente haben wir bereits implizit bei Erstellung der Ubiquitous Language definiert. Die Herausforderung in der Detailmodellierung ist nun, wie wir diese Elemente in einem fachlichen Kontext modellieren. DDD bietet hier das Konzept der Entities und Values. Zunächst stellen sowohl Entities als auch Values fachliche Elemente mit bestimmten Eigenschaften dar. Entities haben in der Fachlichkeit eine eindeutige Identität. Wenn Veränderungen einer Entity erforderlich sind, erfolgen sie in den Eigenschaften dieser. Values hingegen definieren sich ausschließlich über ihre Eigenschaften und besitzen keine eindeutige Identität. Tritt die Erfordernis nach geänderten Eigenschaften auf, wird das bestehende Value durch ein neues Value mit den geänderten Eigenschaften ersetzt.

In unserem Beispiel sind die Elemente Reisebuchung, Kunde und Reise-Betrieb als Entities zu modellieren. Ein Kunde beispielsweise definiert sich nicht ausschließlich über seine Eigenschaften, wie Vor- und Nachname. Ein Verkehrsmittel hat die Eigenschaften Verkehrs-Typ, Startpunkt und Endpunkt. In unserem vereinfachten Beispiel dient das Element lediglich zu optionalen Planungszwecken in der Endanwendung. Die Fachabteilung benötigt hier keine eindeutige Identifikation und das Verkehrsmittel kann als Value modelliert werden.

Durch die Modellierung in Entities und Values rückt der fachliche Zweck der einzelnen Domänenelemente in den Vordergrund.

Aggregates

Wir stehen weiterhin vor der Herausforderung, wie die Abhängigkeiten unter den zuvor modellierten Domänenelementen zu gestalten sind. DDD bietet hierzu das Konzept der Aggregates. Ein Aggregate fasst ein oder mehrere Domänenelemente zusammen, die fachlich gemeinsam relevant sind. Dies kann bedeuten, dass ein Aggregate aus lediglich einer Entity besteht, da diese separat betrachtet werden kann. Jedoch ist es auch möglich, dass eine Entity oder ein Value nur dann fachlich relevant ist, wenn bereits eine andere Entity betrachtet wird. In diesem Fall ist eine Zusammenfassung in einem Aggregate sinnvoll. Die Entity, die hierbei vordergründig betrachtet wird, dient als Einstiegspunkt für das Aggregate und wird als Aggregate-Root bezeichnet. Dies bedeutet insbesondere, dass ein Zugriff auf ein anderes Element des Aggregates nur über das Aggregate-Root möglich ist. Weiterhin wird im Aggregate-Root eine fachliche Invariantenprüfung der Eigenschaften aller Aggregate-Elemente durchgeführt.

In unserem Beispiel sehen wir zunächst, dass die Teams aus der Fachabteilung eine Reisebuchung ohne Notwendigkeit weiterer Entities betrachten. Wir erkennen weiter, dass ein Kunde, ein Reise-Betrieb und ein Verkehrsmittel nur dann fachlich relevant sind, wenn eine Reisebuchung gegeben ist. Wir fassen somit die Entities Reisebuchung, Kunde, Reise-Betrieb und Verkehrsmittel in einem Aggregate zusammen. Die Reisebuchung modellieren wir hierbei als Aggregate-Root. Als fachliche Invariantenprüfung können wir uns beispielsweise vorstellen, dass das Startdatum einer Reisebuchung vor dem Enddatum liegen muss.

Aggregate Reisebuchung

Die Verwendung von Aggregates ermöglicht eine fachliche Gruppierung der Domänenelemente sowie eine lose Kopplung dieser innerhalb einer Subdomain. Die lose Kopplung wird dadurch erreicht, dass nur das Aggregate-Root für Abhängigkeiten außerhalb des Aggregates verwendet wird. Außerdem wird die fachliche Konsistenz erhöht, da eine Invariantenprüfung in den Aggregates angewandt wird.

Fazit

In diesem Blogartikel wurden wiederkehrende Herausforderungen in der Domänenmodellierung nach DDD aufgegriffen. Es wurden Maßnahmen vorgestellt, die diese wiederkehrenden Herausforderungen adressieren. Die Herausforderung eines gemeinsamen Domänenverständnisses wird mit der Ubiquitous Language und dem Bounded Context adressiert. Der Möglichkeit einer hohen Domänenkomplexität wird mit Verwendung mehrerer Subdomains begegnet. Diese kommunizieren über Schnittstellen, die zusammengefasst als Context Map bezeichnet werden. Die Detailmodellierung in einer Subdomain wird mit dem Konzept der Entities und Values adressiert. Schließlich dienen Aggregates zur Festlegung der Abhängigkeiten von Entities und Values in einer Subdomain. Anhand des Beispiels zur Verwaltung und Abrechnung von Reisebuchungen wurde dargelegt, wie die Konzepte angewendet werden können.

Autor Viktor Mucha

Viktor Mucha ist Senior Software Engineer und arbeitet seit 8 Jahren bei adesso in der LOB Lottery. Sein Schwerpunkt liegt in der Konzeption und Entwicklung von Change Requests der Software-Lösung in|FOCUS in Java.

Kategorie:

Architektur

Schlagwörter:

Modellierung

Domain Driven Design

  • adesso.de
  • News
  • Blog
  • Adressierung von Herausforderungen in der Domänenmodellierung

Diese Seite speichern. Diese Seite entfernen.