Bounded Context
Ein Bounded Context legt fest, wo ein fachliches Modell und seine Sprache konsistent gelten. An seiner Grenze werden Bedeutungen ausdrücklich übersetzt oder zugeordnet.
- Eigenes ModellJeder Kontext definiert seine Begriffe selbst.
- GrenzeSie legt fest, wo ein Modell gilt.
- ÜbersetzungAn der Grenze wird Bedeutung zugeordnet.
Einordnung
Warum das wichtig ist
Gleiche Wörter bedeuten im Shop nicht überall dasselbe. Ein Bounded Context grenzt ein Modell samt Sprache ab. Er ist keine Subdomäne: Die gehört zum Problemraum, er zum Lösungsraum. Er ist auch kein Microservice, im Shop ein Modul im Monolithen. Wie Kontexte zusammenhängen, zeigt der Baustein Context Map.
Dieser Baustein erklärt fachliche Modellgrenzen. Für technische Grenzen innerhalb derselben Anwendung siehe Modulgrenzen.
Auf einen Blick · Zwei Kontexte, eine Übersetzung
Ein Modell oder zwei?
Bestellung und Rechnung sind zwei Kontexte im Shop. Beide kennen einen Betrag und einen Status, verwenden diese Begriffe jedoch für unterschiedliche fachliche Zwecke.
So liest du das Bild
- Eigenes Modell Bestellung führt bestellsumme, Rechnung rechnungsbetrag; beide Felder tragen nur eine Bedeutung.
- Grenze Die Grenze trennt Order und Invoice, statt alle Felder in einer Klasse zu sammeln.
- Übersetzung Aus „Bestellung B-1042 bestätigt“ entsteht „Rechnung R-882 offen“ mit zwei Zuordnungen.
ein gemeinsames Modellclass Order
nummer: StringKonflikt: B-1042 oder R-882?status: angelegt | bestätigt | storniert | offen | gestellt | bezahltKonflikt: Kaufauftrag und Forderung teilen ein Feldbetrag: MoneyKonflikt: Bestellsumme oder Rechnungsbetrag?positionen: Liste von Positionenlieferadresse: Adresserechnungsadresse: Adresse
Ein Status und ein Betrag müssen zwei Bedeutungen tragen; jede Änderung an einer Seite trifft die andere.
Nutzen & Grenzen
Hilft, wenn
- Ein Begriff wird in unterschiedlichen Bereichen mit eigenen Regeln verwendet.
- Ein gemeinsames Modell sammelt widersprüchliche Felder oder Sonderbedingungen.
Grenzen
- Zu viele, zu kleine Kontexte: Jede Grenze braucht Übersetzung und Abstimmung. Teile erst, wenn Bedeutungen wirklich auseinanderlaufen; die Context Map zeigt den Aufwand.
- Ein Kontext ist nicht automatisch ein eigener Dienst. Im Shop sind Bestellung und Rechnung Module im modularen Monolithen; den Schnitt prüfst du mit Modulgrenzen.
In der Praxis
- Grenzsignale am Ablauf erkunden. Nutze Event Storming, um mit Fachrollen Ereignisfolgen, Bedeutungswechsel und zusammengehörige Regeln zu untersuchen. Im Shop kann „Status“ bei Bestellung und Rechnung unterschiedliche Modelle anzeigen.
- Begriffe und Regeln pro Bereich erfassen. Sammle, wie Fachrollen Konzepte verwenden und welche Zustände gelten. Das Ergebnis macht semantische Unterschiede konkret.
- Geltungsbereich und Eigentümer festlegen. Benenne, welche Regeln das Modell umfasst und welches Team sie pflegt. Ordne die technische Form erst danach entlang geeigneter Modulgrenzen.
- Übergänge zwischen Kontexten gestalten. Definiere, welche Daten geteilt oder übersetzt werden und wer den Vertrag verantwortet. Eine Context Map hält Richtung und Zusammenarbeit sichtbar.
Ausführliche Erklärung lesen
Ein Begriff kann in verschiedenen Fachbereichen unterschiedliche Regeln und Daten tragen. Innerhalb eines Bounded Contexts gilt ein Modell mit einer konsistenten Sprache und klarer Verantwortung. An einer Kontextgrenze werden benötigte Informationen über Verträge oder Übersetzungen weitergegeben. Domain-Driven Design nutzt diese Abgrenzung strategisch; eine Context Map beschreibt die Beziehungen zwischen Kontexten.
Die fachliche Grenze benennt den Modellbereich; die technische Bereitstellung folgt einer gesonderten Betriebsentscheidung. Ein Kontext kann ein Modul, mehrere Module oder einen eigenständigen Dienst umfassen. Die technische Form folgt weiteren Überlegungen wie Teamverantwortung, Skalierung und Betrieb. Zu viele kleinteilige Kontexte erzeugen Übersetzungs- und Abstimmungsaufwand, während ein einziges globales Modell Bedeutungsunterschiede verwischt.
Eine Subdomäne beschreibt einen Teil des Fachgebiets und gehört zum Problemraum. Ein Bounded Context ist die Modellgrenze, die du dafür wählst, und gehört zum Lösungsraum. Im Shop decken sich beide oft, etwa bei der Rechnung, sie müssen es aber nicht. Die strategische Einordnung beschreibt Domain-Driven Design.
Ereignisfolgen und unterschiedliche Begriffe liefern Hinweise auf mögliche Grenzen, die das Team mit Fachleuten validiert. Für tragfähige Grenzen entscheidend sind zusammengehörige Regeln, Sprache, Verantwortung und Änderungszusammenhänge.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Welche Felder markiert das Bild im gemeinsamen Modell rot, und warum?
Lösung mit Begründung ansehen
nummer, status und betrag. Sie können je nach Kontext Bestellung oder Rechnung meinen und sind deshalb mehrdeutig.
AnwendenAuf eine neue Lage übertragen
Ein Wort wie „Betrag“ bedeutet in zwei Bereichen etwas anderes. Woran erkennst du, ob ein eigener Kontext sinnvoll ist?
Lösung mit Begründung ansehen
Wenn auch Regeln oder Verantwortung abweichen, etwa Bestellsumme beim Kauf und Rechnungsbetrag in der Rechnung, lohnt sich eine Grenze mit Übersetzung.
BewertenEine Alternative abwägen
Das Team will jeden Kontext sofort als Microservice ausrollen. Wie bewertest du das?
Lösung mit Begründung ansehen
Vorteil: klare technische Trennung. Nachteil: Betrieb und Netzwerkaufwand kommen hinzu, obwohl ein Modul im Monolithen die Grenze oft ausreichend trägt. Empfehlung: erst Modulgrenze, Dienst nur bei konkretem Bedarf.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.
Quellen
- Martin Fowler · Bounded Context (öffnet in neuem Tab)Erklärt Modellgrenzen und Beziehungen zwischen unterschiedlichen Fachmodellen.
- DDD Crew · Bounded Context Canvas (öffnet in neuem Tab)Arbeitsvorlage für Zweck, Sprache und Interaktionen eines Bounded Contexts.
- Microsoft · Domain Analysis (öffnet in neuem Tab)Leitet Domänengrenzen und Bounded Contexts aus fachlichen Zusammenhängen ab.
- EventStorming · Alberto Brandolini (öffnet in neuem Tab)Offizielle Einführung in die gemeinsame Erkundung fachlicher Abläufe und komplexer Domänen.