Menü

Domain-driven Design und Bounded Context: Eigentlich ganz einfach, oder?

Die Konzepte von DDD und Bounded Kontext sind in der Praxis komplizierter, als es auf den ersten Blick erscheint.

Lesezeit: 8 Min.
In Pocket speichern
vorlesen Druckansicht Kommentare lesen 16 Beiträge
Von

Inhaltsverzeichnis

Domain-driven Design (DDD) ist einer der wichtigsten Ansätze, um fachliche Funktionalitäten in einem System zu organisieren und abzubilden. Konzepte wie Strategic Design und Bounded Context sind ausgesprochen hilfreich, um grobgranulare Module wie Microservices zu schneiden. Die Konzepte sind im praktischen Einsatz oft komplizierter als gedacht.

Der Begriff "Bounded Context" sagt klar, dass es um einen begrenzten Bereich geht. Ein Bounded Context begrenzt unterschiedliche Dinge:

  • Der Bounded Context definiert den Einsatzbereich eines Domänenmodells. Es umfasst die Geschäftslogik für eine bestimmte Fachlichkeit. Als Beispiel beschreibt ein Domänenmodell die Buchung von S-Bahn-Fahrkarten und ein weiteres die Suche nach S-Bahn-Verbindungen. Da die beiden Fachlichkeiten wenig miteinander zu tun haben, sind es zwei getrennte Modelle. Für die Fahrkarten sind die Tarife relevant und für die Verbindung die Zeit, das Fahrziel und der Startpunkt der Reise.
  • Außerdem soll der Bounded Context den Gültigkeitsbereich einer sogenannten Ubiquitous Language festlegen. Die Bezeichnung lässt sich mit allgegenwärtige Sprache übersetzen und beschreibt eine Menge von Begriffen, die Domänenexperten verwenden und die für Softwareartefakte wie Code oder Datenbank-Schemata genutzt werden sollen. Beispielsweise erschließt sich die Bedeutung des Begriffs "Taktverstärker" nicht sofort, den die Münchener Verkehrsbetriebe für zusätzliche S-Bahn-Züge zu den Stoßzeiten verwenden. Ein System für die Münchner S-Bahn sollte daher einen Taktverstärker als Klassennamen im Code und als Name einer Tabelle im Datenbank-Schema verwenden. Das Beispiel zeigt, dass die Ubiquitous Language ohne Wissen über den fachlichen Kontext nicht zu verstehen ist.
  • Ein Bounded Context sollte in den Zuständigkeitsbereichs genau eines Teams fallen. Ein Team kann für mehr als ein Bounded Context zuständig sein, aber umgekehrt sollten nicht mehrere Teams an einem Bounded Context arbeiten, da das Vorgehen zu viel Abstimmung erfordert.

Somit ist ein Bounded Context ein Gültigkeitsbereich eines Domänenmodells, einer Ubiquitous Language und die Basis für die Organisation des Projekts.

Als Beispiel für ein System nach dem DDD-Gedanken soll eine Bücherei dienen. Zwei wesentliche Funktionalitäten einer Bibliothek sind das Suchen und das Ausleihen von Büchern. Sie unterscheiden sich stark genug, dass zwei unterschiedliche Bounded Contexts sinnvoll erscheinen. Für die Funktionalitäten müssen jeweils Geschäftslogik und Daten über Domänenobjekte wie Bücher oder Leser bereitstehen (s. Abb. 1).

Bounded Context für Suche und Leihe (Abb. 1)

Interessant ist die Entität "Buch" in den beiden Kontexten: Im Bounded Context "Ausleihe" ist ein "Buch" ein konkretes Exemplar, das man in die Hand nehmen kann. Für eine ISBN existieren beliebig viele solcher Bücher.

Für die Suche ist ein "Buch" hingegen eine Sammlung von Daten wie Autor, Titel oder Schlagwörter. Ein solches Buch kann mehrere ISBNs haben, da das gedruckte Buch und das E-Book desselben Titels unterschiedliche ISBNs erhalten. Das Buch in der Suche und in der Leihe sind somit vollständig unterschiedliche Konzepte, die andere Daten haben und eine andere Identität, wie das Verhältnis zur ISBN belegt.

Das Buch hat in der Leihe und in der Suche zudem jeweils einen unterschiedlichen Lebenszyklus: Ein zusätzliches Exemplar erfordert im Kontext der Leihe einen Vermerk, aber in der Suche ändert sich nichts, denn der Sucheintrag existiert ab oder sogar vor dem ersten Exemplar. Bei der Aufnahme eines Buchs in die Suche, muss es in der Leihe noch nicht verfügbar sein. Das Anlegen eines neuen Buchs ist daher nur beim Betrachten in einem bestimmten Bounded Context sinnvoll.

Die inhaltliche Trennung eröffnet die Chance auf mehrere kleine, spezialisierte Domänenmodelle statt übermäßig komplexer großer Domänenmodelle. Das hilft nicht nur bei objektorientierten Modellen, sondern lässt sich ebenso für Datenbankmodelle anwenden, die häufig ebenso viel zu komplex sind.

Nicht nur für die Entwicklung, sondern auch für die Analyse der Domäne ergeben sich Vorteile: Der Begriff "Buch" ist in der Bibliothek offensichtlich nicht eindeutig definierbar. Durch die Bounded Contexts lässt sich in der Analyse damit umgehen, dass "Buch" in unterschiedlichen Bereichen anders definiert sein kann. Innerhalb eines Bounded Context gibt eine eindeutige Definition von "Buch", die aber nicht darüber hinaus gilt [1].

Wenn mehrere Domänenmodelle Informationen über das Buch enthalten, wirkt das wie redundante Datenhaltung, aber wegen der unterschiedlichen Fachlichkeiten haben die Domänenmodelle tatsächlich kaum redundante Daten. Informationen wie die Anzahl der Exemplare gehören eindeutig zur Leihe, Information wie die Schlagwörter hingegen eindeutig zur Suche. Es kann sicher Informationen geben, die in beiden Bounded Context relevant sind, aber weil die beiden Bounded Contexts unterschiedliche Domänenmodelle haben und sogar unterschiedliche Ubiquitous Languages gelten, sind solche redundanten Informationen die Ausnahme.

Spezialisierte, kleine Domänenmodelle sind ein wesentliches Konzept von Domain-driven Design. In der Praxis ist es allerdings manchmal nicht ganz einfach, dieses Konzept umzusetzen. Der Ausgangspunkt für den Entwurf sind die Funktionalitäten der Bounded Contexts. Sie müssen die dafür benötigten Daten und die Logik umfassen. Das entspricht objektorientiertem Design, bei dem die Umgangsformen und Methoden einer Klasse im Mittelpunkt stehen und erst in der Folge die Daten eine Rolle spielen.

Viele Entwürfe gehen jedoch von den Daten aus. Das führt für die beispielhafte Bibliothek zu einem Problem, weil es in beiden Bounded Contexts "Leihe" und "Suche" das "Buch" gibt, es aber in jedem Bounded Context etwas anderes bedeutet. Eine Modellierung nach den Daten führt kaum zu einer Aufteilung in sinnvolle Bounded Contexts, sondern eher zu übermäßig komplexen Modellen. Wichtig ist, die Daten als Folge der Funktionalitäten zu modellieren.