Zum Hauptinhalt springen

Bounded Context (DDD)

Einleitung​

Ein Bounded Context ist das zentrale Strukturprinzip von Domain-Driven Design (DDD).

Er definiert:

Wo ein Modell gültig ist – und wo nicht.

Ein Bounded Context schützt vor:

  • semantischer Mehrdeutigkeit
  • widersprüchlichen Modellen
  • impliziter Kopplung

Das Ziel ist nicht maximale Wiederverwendung,
sondern minimale semantische Kollision.

Einordnung

Ein Bounded Context ist kein technisches Pattern.

Er ist ein konzeptionelles Strukturprinzip auf Domänenebene.

Er beeinflusst:

  • Systemzuschnitt
  • Teamstruktur
  • Integrationsform
  • Architekturentscheidungen

Bounded Contexts können umgesetzt werden als:

  • Modul (im Monolith)
  • Self-Contained System
  • Microservice
  • eigenständiges Subsystem

DDD ist technologieunabhängig –
der Bounded Context ist es ebenfalls.

Grundprinzip

Kernaussage:

  • Begriffe existieren kontextspezifisch
  • Modelle sind nicht global
  • Integration erfordert Übersetzung

Charakteristika

1️⃣ Ubiquitous Language pro Kontext​

  • Begriffe sind klar definiert
  • Gleiche Wörter können unterschiedliche Bedeutungen haben
  • Sprache und Code spiegeln sich

Beispiel:

„Kunde“ im Sales ≠ „Kunde“ im Billing

2️⃣ Eigenes Domänenmodell​

  • Eigene Aggregate
  • Eigene Regeln
  • Eigene Invarianten

Keine geteilten Core-Entities über mehrere Kontexte hinweg.

3️⃣ Explizite Integrationspunkte​

Integration erfolgt über:

  • APIs
  • Events
  • Contracts
  • Anti-Corruption Layer

Nicht über:

  • Shared Database
  • Shared Domain Models

4️⃣ Kontextkarte (Context Map)​

Ein Bounded Context existiert nie isoliert.

Context Maps beschreiben:

  • Upstream/Downstream
  • Conformist
  • Anti-Corruption Layer
  • Shared Kernel
  • Partnership

Ohne Context Map werden Abhängigkeiten unsichtbar.

Vorteile

  • Reduzierte Mehrdeutigkeit
  • Autonome Weiterentwicklung
  • Bessere Änderbarkeit
  • Klare Ownership
  • Skalierbarkeit von Teams

Risiken / typische Fallstricke

1️⃣ God Context​

Zu grob geschnitten → Monolith im neuen Gewand.

2️⃣ Überfragmentierung​

Zu feine Schnitte → Integrations-Overhead explodiert.

3️⃣ Shared Model Illusion​

Gemeinsame Entities über Kontexte hinweg → versteckte Kopplung.

4️⃣ Organisatorische Verwechslung​

Organisationsstruktur ≠ Domänenstruktur.

Teamgrenzen sollten sich an Domänengrenzen orientieren – nicht umgekehrt.

Bounded Context vs. Technische Struktur

Bounded ContextMicroservice
EbeneDomänenkonzeptTechnische Umsetzung
ZielSemantische KlarheitDeployment-Autonomie
Notwendig für DDD?JaNein
Technologiefestlegung?NeinJa

Ein Microservice kann ein Bounded Context sein – muss es aber nicht.

Wann sinnvoll?

  • Mehrere Teams arbeiten an unterschiedlichen Domänen
  • Begriffe haben unterschiedliche Bedeutungen
  • Komplexe Geschäftslogik
  • Langfristige Wartbarkeit wichtiger als kurzfristige Einfachheit

Wann weniger relevant?

  • Sehr kleines System
  • Homogene, stabile Domäne
  • Ein Team verantwortet alles
  • Kaum semantische Konflikte

Typische Kombinationen

  • Modularer Monolith mit klaren Modulgrenzen
  • Self-Contained Systems
  • Microservices pro Kontext
  • Anti-Corruption Layer
  • Event-Driven Integration

Fazit

Ein Bounded Context ist:

  • ein semantischer Schutzraum
  • eine Organisationshilfe
  • ein Architektur-Leitprinzip

Er ist keine technische Lösung, sondern die Grundlage für saubere technische Lösungen.

Ohne klare Kontexte entstehen:

  • verteilte Monolithen
  • Shared Model Chaos
  • organisatorische Reibung