Ein Bounded Context (deutsch etwa „abgegrenzter Kontext“) ist im Domain-Driven Design eine klare Grenze um ein Fachmodell. Innerhalb dieser Grenze haben die Begriffe eine eindeutige, konsistente Bedeutung; außerhalb können dieselben Wörter etwas anderes bedeuten. Der Begriff stammt aus dem „Blue Book“ von Eric Evans (2003) und ist ein zentrales Element des strategischen Designs.
Warum Grenzen nötig sind
Ein klassisches Beispiel ist der Begriff „Kunde“: Im Vertriebs-Bounded Context ist der Kunde eine Person mit Umsatz und Adresse, im Mahnwesen eine Partei mit Zahlungsverhalten, im Versand ein Lieferziel. Würde man alle Bedeutungen in ein einziges Modell pressen, entstünde ein unübersichtlicher „großer Brei“ (Big Ball of Mud). Jeder Kontext besitzt deshalb sein eigenes Modell und seine eigene Ubiquitous Language.
Context Mapping
Die Beziehungen zwischen Bounded Contexts beschreibt eine Context Map. Evans und Vernon definieren dafür Muster:
- Shared Kernel: Ein kleines gemeinsames Modell wird geteilt und gemeinsam weiterentwickelt.
- Customer/Supplier: Der stromaufwärts gelegene Kontext liefert, der stromabwärts gelegene bestimmt die Anforderungen.
- Conformist: Der nachgelagerte Kontext übernimmt das Modell des Lieferanten ohne eigene Anpassung.
- Anti-Corruption Layer: Eine Übersetzungsschicht schützt das eigene Modell vor fremden, oft älteren Systemen.
- Open Host Service / Published Language: Der Kontext stellt eine stabile öffentliche Schnittstelle bereit.
- Separate Ways: Die Kontexte entwickeln sich vollständig getrennt.
Praxis
Bounded Contexts sind die natürliche Grundlage für Microservices: Jeder Dienst implementiert genau einen Kontext. Die Kommunikation zwischen Kontexten erfolgt über klar definierte Schnittstellen — häufig über Event-Busse oder Event-Streams, etwa beim Event Sourcing mit einer Transactional Outbox.
Verwandte Grundlagen: Domain-Driven Design, Ubiquitous Language, Kapselung, Saga-Muster, Verteilte Systeme.