Customer–Supplier Pattern
Einleitung
Das Customer–Supplier Pattern beschreibt eine gerichtete, aber kooperative Beziehung zwischen zwei Bounded Contexts.
Ein Kontext (Supplier):
- stellt Fähigkeiten oder Daten bereit
- besitzt das Modell
- verantwortet Schnittstellen
Ein anderer Kontext (Customer):
- konsumiert diese Fähigkeiten
- formuliert Anforderungen strukturiert
- hat legitimen Einfluss auf die Weiterentwicklung
Im Unterschied zum Conformist-Pattern besteht hier bewusste Zusammenarbeit statt reiner Anpassung.
Einordnung
Customer–Supplier ist ein strategisches Context-Mapping-Pattern in DDD.
Es modelliert:
- explizite Abhängigkeiten
- Machtverhältnisse
- Einflussmechanismen
- Verantwortlichkeiten
Es gehört zur Domänen- und Organisationsebene, nicht zur Infrastruktur.
Grundprinzip
Kernaussage:
- Die Abhängigkeit ist gerichtet
- Einfluss ist strukturiert
- Zusammenarbeit ist bewusst organisiert
Charakteristika
1️⃣ Klare Rollen
- Supplier besitzt Modell und Implementierung
- Customer besitzt legitime Anforderungen
- Verantwortung ist transparent
Der Supplier entscheidet technisch – der Customer beeinflusst strategisch.
2️⃣ Verhandelte Schnittstellen
- Roadmap-Abstimmung
- API-Versionierung
- Breaking-Change-Regeln
- Deprecation-Zyklen
Schnittstellen sind keine Zufallsprodukte, sondern Vereinbarungen.
3️⃣ Governance statt impliziter Macht
Customer–Supplier funktioniert nur mit:
- klaren Kommunikationskanälen
- definierten Eskalationspfaden
- priorisierten Backlogs
Ohne Governance wird aus Kooperation schnell Conformist oder Chaos.
Vorteile
- Steuerbare Abhängigkeiten
- Stabilere Integrationsbeziehungen
- Planbare Weiterentwicklung
- Transparente Einflussmechanismen
Risiken / typische Fallstricke
1️⃣ Supplier wird Bottleneck
Viele Customers → Priorisierungskonflikte und Überlastung.
2️⃣ Politische Spannungen
Produktziele des Suppliers vs. Anforderungen der Customers.
3️⃣ Scheinkooperation
Formal Customer–Supplier, real faktisch Conformist (kein echter Einfluss).
4️⃣ Governance-Overhead
Zu viel Abstimmung kann Delivery verlangsamen.
Wann sinnvoll?
- Ein Kontext liefert zentrale Fähigkeiten
- Mehrere Downstreams existieren
- Schnittstellen sollen langfristig stabil bleiben
- Beide Seiten sind strategisch relevant
Wann problematisch?
- Keine organisatorische Kooperationskultur
- Supplier ist unterdimensioniert
- Hohe Änderungsdynamik
- Abhängigkeit wäre durch Entkopplung vermeidbar
Vergleich mit anderen Context-Mapping-Patterns
| Pattern | Einfluss des Downstream | Übersetzung | Autonomie |
|---|---|---|---|
| Conformist | Kein Einfluss | Nein | Niedrig |
| Customer–Supplier | Strukturierter Einfluss | Nein | Mittel |
| Anti-Corruption Layer | Kein Einfluss | Ja | Hoch |
| Partnership | Gegenseitige Entwicklung | Optional | Hoch |
Typische Kombinationen
- API-Versionierung
- Consumer-Driven Contract Tests
- SLO-/SLA-Definitionen
- Klare Deprecation-Strategien
- Optional späterer ACL bei wachsender Autonomie
Strategische Perspektive
Customer–Supplier ist:
- realistischer als reine Autonomie
- kooperativer als Conformist
- kontrollierter als implizite Abhängigkeit
Es macht Abhängigkeit explizit – und damit steuerbar.
Fazit
Customer–Supplier ist ein strategisches Beziehungsmodell zwischen Bounded Contexts.
Es funktioniert gut, wenn:
- Rollen klar definiert sind
- Governance etabliert ist
- beide Seiten langfristig denken
Ohne Struktur wird es:
- politisch
- instabil
- oder faktisch Conformist.