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

Keine grünen Wiesen mehr

Inhaltsverzeichnis

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 hat ein Modell mit allen Daten eines Buchs. Wie erwähnt ist eine Aufteilung in mehrere Modelle mit spezialisierten Modellierungen des Buchs beispielsweise für Suche oder Leihe wesentlich sinnvoller.
  • Ein System, das lediglich Daten verwalten soll, implementiert keine Funktionalitäten, die Grundlage für die Aufteilung nach Bounded Context ist. Systeme, die nur Daten verwalten, bilden die wesentliche Domänenlogik nicht ab.

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)

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)

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.