zurück zum Artikel

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

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.

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:

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)

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.

Es gibt kaum Projekte, bei denen Systeme auf der grünen Wiese entstehen. Meistens gibt es andere IT-Systeme, die es zu integrieren oder abzulösen gilt. Beispielsweise könnte in der Bibliothek ein Buchsystem existieren, das alle Informationen zu Büchern umfasst und das in einem Widerspruch zu der erläuterten, idealen Modellierung steht:

Das Buchsystem erfüllt dennoch ein Merkmal eines Bounded Context: Es hat ein eigenes Domänenmodell. Es verwaltet alle Informationen über Bücher.

Ein anderes Merkmal eines Bounded Context erfüllt das Buchsystem nicht: Es setzt keine Ubiquitous Language um. Weil das System alle Informationen zu einem Buch verwaltet, setzt es sie weder für die Leihe noch die für die Suche um. Das Datenmodell hat vermutlich eine Klasse "Buch", aber das Datenmodell muss die Daten für Leihe, Suche und gegebenenfalls einige weitere Funktionalitäten implementieren. Daher kann die Klasse "Buch" im Buchsystem keiner der beiden Ubiquitous Languages entsprechen und somit keinem der Begriffe der Domänenexperten.

Es gibt also Domänenmodelle, die keine Ubiquitous Language abbilden. Im Beispiel müsste ein solches Modell alle Informationen für Bücher verwalten. Dabei geht es nicht nur um die Anzahl der Attribute, sondern auch darum, die Konzepte "Buch" in Leihe und Suche abzubilden. Da sie grundverschieden sind, entsteht ein kompliziertes und wegen der Mehrdeutigkeiten verwirrendes Modell. Zudem ändert sich bei jeder fachlichen Änderungen an der Leihe oder der Suche der Bücherservice, wenn sich etwas an der Modellierung der Bücher ändert. Auf die Weise kann er zu einem Änderungsschwerpunkt werden, den es bei jeder fachlichen Änderungen anzupassen gilt.

Die spezialisierten Modelle sind auf jeden Fall kleiner, einfacher und weniger verwirrend. Sie versprechen zudem, dass Änderungen mit einer höheren Wahrscheinlichkeit nur ein Domänenmodell umfassen. Eines der zentralen Versprechen von Bounded Contexts ist, dass mehrere kleinere Domänenmodelle oft ein besserer Weg sind, um mit der Komplexität umzugehen.

Beim Umgang mit dem Buchsystem sollten die Verantwortlichen somit eine Ablösung erwägen, um die Vorteile von Domain-driven Design vollständig umzusetzen. Das ist jedoch eventuell aufwendig, da das Domänenmodell in dem Buchsystem komplex ist. Außerdem kann das System Abhängigkeiten zu vielen anderen Systemen haben. Schließlich kommt in einer Bibliothek wohl kaum ein IT-System ohne Informationen über Bücher aus, die sich das jeweilige System vom Buchsystem holt.

Wegen der Komplexität der Domänenmodelle kann es dennoch eine gute Idee sein, von solchen Systemen weg zu migrieren oder sie zumindest nicht weiter wachsen zu lassen. Dazu lässt sich ein neues System mit einem Bounded Context wie "Leihe" oder "Suche" implementieren, das zunächst die benötigten Daten aus dem Buchsystem repliziert. Das Buchsystem bleibt zunächst für die Daten führend.

Wenn der neue Bounded Context später für die Informationen führend ist, lässt sich die Richtung der Replikation umkehren. Dann erfolgt beispielsweise die Verwaltung der Information über die Anzahl der vorhandenen Exemplare im Bounded Context Leihe und das Buchsystem hat nur eine Kopie der Informationen. Gegebenenfalls ist die Anzahl der Exemplare nur für die Leihe relevant. In dem Fall lässt sich auf das Replizieren der Daten verzichten. Weil die benötigten Daten eine Folge der im Bounded Context implementierten Funktionalitäten sind, ist es sogar recht wahrscheinlich, dass nur ein Bounded Context die Information benötigt.

Wenn es dennoch andere Systeme gibt, die an der Anzahl der Exemplare interessiert sind, wenden sie sich nicht mehr an das Buchsystem, sondern den Bounded Context "Leihe". Nach der Umsetzung verschwinden diese Informationen aus dem Buchsystem, dessen Komplexität dadurch sinkt. Nach und nach lässt sich das Buchsystem eliminieren.

Dabei handelt es sich um einen langwierigen Prozess, da das Ablösen eines solchen Abhängigkeitsschwerpunkts nur mit erheblichen Aufwand realisierbar ist. Weit vor der endgültigen Ablösung ergibt sich der Vorteil, dass die Leihe nun ein eigenes kleines Domänenmodell hat, das wesentlich einfacher zu verstehen und weiterzuentwickeln ist. Das kann sofort zu einem Produktivitätsvorteil führen, um neue Anforderungen in dem Bounded Context Leihe umzusetzen. Es kann durchaus sein, dass der Aufwand für eine vollständige Migration keine ausreichende Produktivitätssteigerung zur Folge hat und es daher nie zur vollständigen Ablösung des Buchsystems kommt.

Buchsystem und Bounded Context für Leihe (Abb. 2)

Buchsystem und Bounded Context für Leihe (Abb. 2)

Bisher standen nur einzelne Bounded Contexts im Fokus, aber ein Bounded Context kann nicht in Isolation existieren. Wenn Leser nach einem Buch suchen, sollte sich idealerweise ein Leihvorgang anschließen. Dazu ist eine Schnittstelle notwendig, mit der die Suche der Leihe Informationen übergeben kann, sodass Büchereibesucher das richtige Buch ausleihen können.

Domain-driven Design behandelt Beziehungen zwischen Bounded Contexts im Strategic Design. In diesem Bereich existieren unterschiedliche Patterns: Bei Customer/Supplier kann das Team, das für "Leihe" verantwortlich ist, dem Team, das für "Suche" verantwortlich ist, Anforderungen geben, die letzteres Team umsetzen muss.

Beim Open-Host-Service würde hingegen die "Suche" anderen Systemen eine generische Schnittstelle anbieten, die auch die "Leihe" nutzen kann. Open-Host-Service hält dadurch die Anzahl der Schnittstellen gering. Ein Open-Host-Service hat organisatorische Auswirkung: Wer den Service verantwortet, nimmt zwar Anforderungen anderer Teams entgegen, aber am Ende entscheidet das Team, ob es die Anforderungen umsetzt oder die Anforderungen in der generischen Schnittstelle nicht berücksichtigt, weil sie zu speziell sind. Das letzte Wort liegt dazu bei dem Team, das den Open-Host-Service verantwortet.

Strategic Design scheint Beziehungen zwischen Teams festzulegen. In Wirklichkeit handelt es sich jedoch um Beziehungen zwischen Kontexten: Das Team, das einen Bounded Context verantwortet, übernimmt die damit verbundenen Rechte und Pflichten. Das für einen Bounded Context verantwortliche Team muss nicht konstant sein, da die Änderungsschwerpunkte über den Verlauf eines Projekts nicht gleich bleiben. Um dennoch die Teams gleichmäßig auszulasten, müssen sie Bounded Contexts tauschen.

Beispielsweise kann anfangs je ein Team das Buchsystem, die Leihe und die Suche verantworten. Das Buchsystem ist ein Open-Host-Service, sodass das "Suche"-Team und das "Leihe"-Team Anforderungen stellen können, die das "Buchsystem"-Team umsetzt, wenn sie in den Plan des Teams passen. Letzteres Team könnte nun die Verantwortung für das "Buchsystem" an das "Leihe"-Team übergeben. Das Buchsystem bleibt dabei ein Open-Host-Service. Das "Leihe"-Team muss somit die Anforderungen von "Suche" an das "Buchsystem" entgegennehmen, bewerten und gegebenenfalls im "Buchsystem" umsetzen, weil es die Pflichten mit der Übernahme des "Buchsystems" übernommen hat.

Buchsystem, Suche und Leihe und die Beziehungen (Abb. 3)

Buchsystem, Suche und Leihe und die Beziehungen (Abb. 3)

Die Beziehungen zwischen den Bounded Contexts wie in den Abbildungen 2 und 3 stellen eine Context Map dar. die oft zur Darstellung des Sollzustand eines Systems dienen. In einem IT-System oder einer IT-Landschaft gibt es jedoch bereits Domänenmodelle, zwischen denen Beziehungen existieren. Eine Context Map lässt sich zur Analyse des Ist-Zustands nutzen. Damit sind Bounded Contexts wie ein Buchsystem die Regel: Sie haben zwar ein Domänenmodell, aber entsprechen keiner Ubiquitous Language, weil sie ohne Rücksicht auf die Erkenntnisse von DDD entstanden sind. Bei einem Sollmodell entsprechen mehr Bounded Contexts dem DDD-Ideal, wenn eine Migration in Richtung DDD geplant ist.

Bei den Beziehungen zwischen den Bounded Contexts können andere Patterns auftreten als im Domain-driven Design vorgesehen. Beispielsweise kann das Buchsystem zwar eine generische API anbieten, aber das "Buchsystem"-Team hat nicht das letzte Wort, welche Änderungen tatsächlich in die API fließen. Ein Grund dafür könnte sein, dass ein anderes Team politisch mächtiger ist und seine Anforderungen auf jeden Fall durchsetzen kann. Die Abhängigkeiten und Schnittstellen auf der Software-Ebene sind dann genau so wie bei einem Open Host Service, aber die Beziehungen auf Team-Ebene unterscheiden sich.

Obwohl die Unterschiede als Detail erscheinen mögen, haben sie potenziell erhebliche Konsequenzen. Wenn das Team nicht die Möglichkeit hat, die Entwicklung der API zu steuern, kann es passieren, dass die API irgendwann schwer zu verstehen und zu benutzen ist, weil sie keinem eindeutigen Konzept mehr folgt. Weil Abweichungen von den DDD-Pattern zu Herausforderungen führen können, ist es wichtig, die Beziehungen präzise zu dokumentieren und Abweichungen gegebenenfalls zu untersuchen. Es kommt durchaus vor, dass Abweichungen sinnvoll sind oder nicht zu Problemen führen. In dem Fall ist es nicht unbedingt notwendig, die Beziehungen zu ändern.

Auf drei unterschiedlichen Ebenen existieren Bounded Contexts: dem Datenmodell, der Ubiquitous Language und den Teams.

Bounded Contexts haben spezialisierte Datenmodelle. In jedem der Datenmodelle kann es gleich benannte Domänenobjekte wie "Buch" geben, die aber meistens keine redundanten Daten enthalten, sondern unterschiedliche fachliche Aspekte eines solchen Domänenobjekts modellieren. Die Aufteilung in mehrere kleine Datenmodelle ist ein wesentlicher Grund, warum DDD-Entwürfe einfacher sein können. Gleichzeitig ist es oft eine Hürde zu akzeptieren, dass unterschiedliche Datenmodelle Informationen über ein Domänenobjekt wie ein Buch haben.

Die Ubiquitous Language stellt eine Sammlung von Begriffen dar, die Domänenexperten nutzen und sich in der Software wiederfinden sollten. Für die Leihe und die Suche ist das Buch etwas anderes. Mit einem Bounded Context können mehrdeutige Begriffe eindeutig werden. Ein Buchsystem durchbricht dieses Design, weil es alle Informationen zu dem Buch sammelt und beide Ubiquitous Languages umfassen muss. Es zeigt somit, dass ein Bounded Context mit einem Domänenmodell nicht unbedingt ebenfalls einer für eine Ubiquitous Language sein muss.

Ein Bounded Context definiert die Rechte und Pflichte des Teams, das dafür verantwortlich ist. Wenn ein anderes Team ihn übernimmt, erhält es damit auch die Rechte und Pflichten.

Weil ein Bounded Context also verschiedene Aspekte umfasst, erscheint es sinnvoll, Bounded Contexts für Domänenmodelle und Bounded Contexts für die Ubiquitous Languages zu unterscheiden – auch wenn Domain-driven Design das nicht direkt vorsieht.

Schließlich ist es wichtig, die Aufteilung in Bounded Contexts zu analysieren und den Ist-Zustand klar von einem möglichen Sollzustand abzugrenzen. In bereits vorhandenen Legacy-Systemen existieren auf jeden Fall Bounded Contexts für Domänenmodelle, aber solche für Ubiquitous Languages finden sich gegebenenfalls nicht wieder, weil Systeme Daten aus mehreren Ubiquitous Languages verwalten. Gerade diese Erkenntnisse sind interessant, um Systeme zu verbessern und weiterzuentwickeln.

Der Autor dankt seinen Kollegen Martin Kühl, Tammo van Lessen, Martin Otten, Joachim Praetorius und Johannes Seitz für die Kommentare zu einer früheren Version des Artikels.

Eberhard Wolff
arbeitet als Fellow bei INNOQ. Er ist seit mehr als 15 Jahren als Architekt und Berater tätig – oft an der Schnittstelle zwischen Business und Technologie. Sein technologischer Schwerpunkt liegt auf modernen Architekturansätzen – Cloud, Continuous Delivery, DevOps, Microservices oder NoSQL spielen oft eine Rolle.

  1. Eric Evans: Domain-driven Design Referenz [1], kostenlos

(rme [2])


URL dieses Artikels:
https://www.heise.de/-4634258

Links in diesem Artikel:
[1] https://ddd-referenz.de/
[2] mailto:rme@ct.de