Bounded Context
Konzept aus Domain-Driven Design zur klaren Abgrenzung von Begriffen, Regeln und Modellen zwischen Kontextgrenzen.
Klassifikation
- KomplexitätMittel
- AuswirkungOrganisatorisch
- EntscheidungstypArchitektur
- OrganisationsreifeFortgeschritten
Technischer Kontext
Prinzipien & Ziele
Use Cases & Szenarien
Kompromisse
- Falsche Abgrenzungen führen zu Fragmentierung
- Übermäßige Kontextanzahl erhöht Komplexität
- Unklare Verträge verursachen Integrationsfehler
- Kontextkarten regelmäßig pflegen und versionieren
- Eigentümerschaft pro Kontext klar benennen
- Integrationen über gut definierte, getestete Verträge realisieren
I/O & Ressourcen
- Domänenwissen und Glossare
- Stakeholder-Interviews und Use Cases
- Bestehende System- und Integrationsübersichten
- Kontextkarte mit Abgrenzungen
- API‑Verträge und Integrationsrichtlinien
- Empfehlungen zur Service-Zerlegung
Beschreibung
Ein Bounded Context definiert klar abgegrenzte Modellgrenzen innerhalb eines Domänenmodells, in denen Begriffe, Regeln und Schnittstellen kohärent und konsistent sind. Er verhindert Bedeutungsverschiebungen zwischen Teams, erleichtert autonome Entwicklung und Integration und bildet die Grundlage für klare Kontextgrenzen in verteilten Systemen und Microservice-Architekturen. Die klare Abgrenzung unterstützt Versionierung, Eigentümerschaft und überschaubare Schnittstellenverträge.
✔Vorteile
- Reduzierte semantische Verwirrung zwischen Teams
- Erleichterte autonome Entwicklung und Deployment
- Klarere Integrations- und Versionierungsstrategien
✖Limitationen
- Erhöhter Abstimmungsaufwand beim Mapping mehrerer Kontexte
- Nicht alle Domänen lassen sich ohne Kompromisse sauber trennen
- Initialer Modellierungs- und Dokumentationsaufwand
Trade-offs
Metriken
- Anzahl der Kontextgrenzen
Zählt definierte Bounded Contexts zur Einschätzung der Zerlegung
- Schnittstellenänderungen pro Sprint
Misst Stabilität der Verträge zwischen Kontexten
- Cross-Context Fehlerrate
Fehler beim Austausch zwischen Bounded Contexts als Qualitätsindikator
Beispiele & Implementierungen
E-Commerce Bestellkontext
Bestellprozess als eigener Bounded Context mit eigenem Modell und API gegenüber Lager und Zahlung.
Kundenverwaltung vs. Abrechnung
Kundenstammdaten und Abrechnungsdaten in getrennten Kontexten mit synchronisierten Verträgen.
Shipping-Service im Microservice-Architektur
Versandlogik als eigenständiger Bounded Context zur Reduzierung von Kopplung und Domänenkonflikten.
Implementierungsschritte
Workshops zur Begriffsabstimmung durchführen und Kontextkarte erstellen.
Kontextgrenzen priorisieren und Pilotszenario auswählen.
Schnittstellenverträge definieren, implementieren und testen.
⚠️ Technische Schulden & Engpässe
Tech Debt
- Unklare oder fehlende Vertragsspezifikationen
- Monolithische Abhängigkeiten trotz definierter Kontexte
- Temporäre Ad-hoc-Schnittstellen ohne Tests
Bekannte Engpässe
Beispiele für Missbrauch
- Grenzen nur aus technischer Infrastruktur ableiten statt aus Domäne
- Kontexte nicht dokumentieren und dadurch Integrationsprobleme verursachen
- Kontextwechsel ohne Versionierung und Migrationsplan
Typische Fallen
- Verwechslung von Teamgrenzen und fachlichen Grenzen
- Zu frühe Zerlegung ohne stabile Domänenkenntnis
- Ignorieren von Integrationskosten zwischen Kontexten
Erforderliche Fähigkeiten
Drivers (Architectural Drivers)
Constraints
- • Organisatorische Grenzen und Teamstrukturen
- • Legacy-Systeme mit engen Kopplungen
- • Regulatorische Anforderungen an Datenhaltung