Bounded Context, Ubiquitous Language und Domänenmodell
Der Bounded Context ist eng mit zwei weiteren DDD-Grundbegriffen verbunden. Das Domänenmodell ist nach Evans ein System von Abstraktionen, das ausgewählte Aspekte einer Fachdomäne beschreibt und zur Lösung fachlicher Probleme dient. Ein Modell ist also nie ein vollständiges Abbild der Wirklichkeit, sondern eine bewusste Auswahl. Genau deshalb braucht es einen Rahmen, in dem diese Auswahl gilt.
Die Ubiquitous Language ist die gemeinsame Sprache, die Fachexperten und Entwickler innerhalb eines Bounded Context konsequent verwenden: im Gespräch, in Diagrammen, in Tickets und vor allem im Code. Klassen, Methoden und Module tragen die Namen, die auch die Fachabteilung benutzt. Ändert sich die Sprache, ändert sich das Modell.
Entscheidend ist der Zusatz „innerhalb“. Eine Ubiquitous Language ist nie unternehmensweit gültig. Sie gilt genau in einem Bounded Context. Der Kontext ist damit die Sprachgrenze, an der Begriffe ihre Bedeutung wechseln dürfen. Fowler nennt solche mehrdeutigen Wörter Polyseme und zeigt am Beispiel eines Energieversorgers, wie das Wort „Zähler“ je nach Abteilung einen Netzanschluss, eine Kundenbeziehung oder das physische Gerät bezeichnete.
Wie findest du die Grenzen eines Bounded Context?
Es gibt kein Rechenverfahren, das Kontextgrenzen automatisch liefert. In der Praxis haben sich drei Signale bewährt, die du kombinieren solltest. Wie das in einem konkreten Projekt abläuft, beschreibt der Beitrag Domain-Driven Design in der Praxis ausführlicher.
Sprachunterschiede als stärkstes Signal
Achte darauf, wo dasselbe Wort unterschiedliche Attribute, Regeln oder Lebenszyklen bekommt. Wenn die Buchhaltung beim „Kunden“ an Zahlungsbedingungen und Bonität denkt, der Support aber an Tickets und Ansprechpartner, liegt vermutlich eine Kontextgrenze dazwischen. Umgekehrt sind zwei verschiedene Wörter für dasselbe Konzept ein Hinweis, dass die Sprache innerhalb eines Kontexts noch nicht geklärt ist.
Event Storming als Workshop-Methode
Das von Alberto Brandolini entwickelte Event Storming ist ein Workshop-Format, in dem Fachleute und Entwickler fachliche Ereignisse auf einer langen Zeitachse sammeln, etwa „Angebot versendet“ oder „Maschine ausgeliefert“. Die offizielle EventStorming-Seite beschreibt es als flexibles Format zur gemeinsamen Erkundung komplexer Geschäftsdomänen. Wo sich Zuständigkeiten, Begriffe oder Taktung der Ereignisse ändern, zeichnen sich Kandidaten für Kontextgrenzen ab.
Teamgrenzen und Conway's Law
Melvin Conway formulierte 1968 im Magazin Datamation in seinem Aufsatz „How Do Committees Invent?“ die These, dass Organisationen Systeme entwerfen, deren Struktur ihre Kommunikationsstruktur kopiert. Für Bounded Contexts heißt das: Ein Kontext, den drei Teams gemeinsam verantworten, läuft Gefahr, in drei verschiedene Modelle zu zerfallen. Plane Kontexte deshalb so, dass jeder genau einem Team gehört. Ein Team darf durchaus mehrere Kontexte betreuen.
Context Mapping: Wie Bounded Contexts zusammenarbeiten
Ein einzelner Bounded Context löst nur die Hälfte des Problems. Systeme müssen Daten austauschen, und an jeder Verbindungsstelle droht ein Modell in das andere „auszulaufen“. Deshalb empfiehlt Evans eine Context Map: eine Übersicht, die jedes Modell im Projekt benennt, seinen Kontext abgrenzt und die Kontaktpunkte beschreibt, inklusive Übersetzungen, geteilter Teile und Machtverhältnisse.
Wichtig dabei ist ein Satz aus der DDD Reference: „Map the existing terrain.“ Die Context Map zeigt zuerst den Ist-Zustand, einschließlich unschöner Altlasten. Umbauten plant man erst danach. Viele Muster beschreiben dabei eine Upstream/Downstream-Beziehung: Das Upstream-Team beeinflusst mit seinen Entscheidungen den Erfolg des Downstream-Teams, aber nicht umgekehrt.
Die DDD Reference ergänzt außerdem den Big Ball of Mud als Muster für Bereiche ohne erkennbare Modellgrenzen. Partnership und Big Ball of Mud kennzeichnet Evans dort ausdrücklich als Begriffe, die erst nach dem ursprünglichen Buch hinzukamen. Für die Anbindung von Legacy-Software ist der Anticorruption Layer besonders relevant, weil er laut Evans kaum oder keine Änderungen am Altsystem erfordert.
Bounded Context vs. Subdomain vs. Microservice vs. Modul
Diese vier Begriffe werden oft vermischt, beschreiben aber verschiedene Dinge. Eine saubere Trennung hilft dir bei Architekturentscheidungen.
- Subdomain gehört zum Problemraum: Sie ist ein fachlicher Teilbereich des Geschäfts, etwa Vertrieb, Fertigung oder Kundendienst. Evans unterscheidet die Core Domain, also das, was dein Unternehmen auszeichnet, von generischen Subdomänen. Vaughn Vernon ergänzt in „Implementing Domain-Driven Design“ (2013) unterstützende Subdomänen.
- Bounded Context gehört zum Lösungsraum: Er ist die Grenze, in der ein konkretes Modell gilt. Idealerweise deckt ein Kontext genau eine Subdomain ab, in gewachsenen Systemen ist das selten der Fall.
- Microservice ist eine Deployment-Einheit, also ein unabhängig auslieferbarer Prozess. Ein Bounded Context kann aus mehreren Microservices bestehen. Ein Microservice sollte aber nie mehrere Kontexte vermischen.
- Modul ist eine Code-Struktur innerhalb einer Anwendung. In einem modularen Monolithen bildet jedes Modul einen Bounded Context ab, mit eigener Sprache, eigenem Datenzugriff und klarer Schnittstelle, aber gemeinsamem Deployment.
Der modulare Monolith ist für viele Mittelstandssysteme ein vernünftiger Startpunkt. Martin Fowler argumentiert in seinem Beitrag „MonolithFirst“ vom Juni 2015, dass stabile Service-Grenzen im Kern das Ziehen der richtigen Bounded Contexts bedeuten und dass selbst erfahrene Architekten diese Grenzen zu Beginn oft falsch setzen. In einem Monolithen lassen sich Fehlschnitte deutlich billiger korrigieren als zwischen verteilten Services.
Beispiel: „Auftrag“ bei einem fiktiven Maschinenbauer
Das folgende Szenario ist ein bewusst vereinfachtes, hypothetisches Beispiel. Ein mittelständischer Maschinenbauer fertigt Verpackungsanlagen und betreibt Vertrieb, Produktion und Service. Alle drei Abteilungen sprechen täglich vom „Auftrag“, meinen aber etwas anderes:
- Vertrieb: Der Auftrag ist ein Kundenauftrag mit Konfiguration, Preis, Rabatt, Zahlungsbedingungen und zugesagtem Liefertermin. Sein Lebenszyklus endet mit der Auftragsbestätigung und später der Rechnung.
- Produktion: Der Auftrag ist ein Fertigungsauftrag mit Stückliste, Arbeitsplan, Losgröße und Maschinenbelegung. Preise spielen hier keine Rolle. Aus einem Kundenauftrag können mehrere Fertigungsaufträge entstehen.
- Service: Der Auftrag ist ein Serviceauftrag zu einer konkreten, bereits ausgelieferten Anlage mit Seriennummer, Störungsbild, Techniker, Ersatzteilen und Reaktionszeit.
Ein einziges Datenmodell „Auftrag“ für alle drei Bereiche würde zur Sammeltabelle mit Dutzenden optionaler Felder, deren Bedeutung nur noch Eingeweihte kennen. Mit drei Bounded Contexts bekommt jeder Bereich sein eigenes, schlankes Modell. Verbunden werden sie über stabile Kennungen wie Auftragsnummer und Seriennummer sowie über fachliche Ereignisse.
Bestätigt der Vertrieb einen Kundenauftrag, veröffentlicht sein Kontext etwa das Ereignis „Kundenauftrag bestätigt“. Die Produktion übersetzt es in eigene Fertigungsaufträge. Hängt die Produktion zusätzlich an einem älteren ERP-System, schützt ein Anticorruption Layer das Fertigungsmodell vor dessen Datenstrukturen. Der Service-Kontext übernimmt nach Auslieferung nur Anlagendaten und Seriennummer, nicht aber Preise oder Arbeitspläne.
Typische Fehler beim Schneiden von Bounded Contexts
- Bounded Context mit Microservice gleichsetzen. Wer jeden Kontext sofort als eigenen Service ausrollt, zahlt früh den Aufwand verteilter Systeme, bevor die Grenzen stabil sind.
- Nach technischen Schichten schneiden. „Frontend“, „Backend“ und „Datenbank“ sind keine fachlichen Kontexte. Grenzen folgen der Sprache und den Geschäftsregeln.
- Ein unternehmensweites Einheitsmodell anstreben. Evans hält eine vollständige Vereinheitlichung des Domänenmodells großer Systeme für weder machbar noch wirtschaftlich. Das kanonische „Kunde für alle“-Objekt erzeugt genau die Mehrdeutigkeit, die Kontexte vermeiden sollen.
- Datenbanktabellen heimlich teilen. Greifen zwei Kontexte auf dieselben Tabellen zu, entsteht ein ungeplanter Shared Kernel ohne Absprache. Jede Schemaänderung wird zum Risiko und erhöht die technische Schuld.
- Nur das Zielbild zeichnen. Eine Context Map, die den Ist-Zustand ausblendet, verschweigt die tatsächlichen Abhängigkeiten und führt zu unrealistischen Migrationsplänen.
- Teamstrukturen ignorieren. Kontexte ohne eindeutigen Eigentümer verwässern, weil niemand über die Sprache und das Modell entscheidet.
Häufige Fragen zu Bounded Context
Wie groß sollte ein Bounded Context sein?
Eine feste Größe gibt es nicht. Ein Kontext ist richtig geschnitten, wenn seine Sprache in sich widerspruchsfrei ist, ein Team ihn verantwortet und er sich mit überschaubaren Schnittstellen an andere Kontexte anbinden lässt. Zu kleine Kontexte erzeugen viel Integrationsaufwand, zu große verlieren ihre sprachliche Klarheit. Evans weist selbst darauf hin, dass immer kleinere Kontexte irgendwann wertvolle Kohärenz kosten.
Ist ein Bounded Context dasselbe wie ein Microservice?
Nein. Der Bounded Context ist eine fachliche Modellgrenze, der Microservice eine technische Auslieferungseinheit. Ein Kontext kann als Modul in einem Monolithen, als ein Service oder als Gruppe mehrerer Services umgesetzt werden. Umgekehrt sollte ein Service nie Modelle aus mehreren Kontexten vermischen.
Was ist der Unterschied zwischen Subdomain und Bounded Context?
Die Subdomain beschreibt einen fachlichen Teilbereich des Geschäfts, also das Problem. Der Bounded Context beschreibt die Grenze eines Software-Modells, also die Lösung. Im Idealfall entsprechen sie sich eins zu eins. In gewachsenen Systemen deckt ein Kontext oft mehrere Subdomänen ab, was ein Hinweis auf Umbaubedarf sein kann.
Lohnen sich Bounded Contexts auch ohne vollständiges DDD?
Ja. Schon eine einfache Context Map deiner bestehenden Systeme macht Abhängigkeiten, Übersetzungsstellen und Begriffskonflikte sichtbar. Die strategischen DDD-Muster lassen sich auch nutzen, ohne die taktischen Bausteine wie Aggregates oder Repositories konsequent einzusetzen. Gerade bei der Ablösung von Altsystemen ist das Kontextdenken der wertvollere Teil.
