Context Map
Eine Context Map zeigt Bounded Contexts und ihre fachlichen Beziehungen. Sie macht Abhängigkeiten, Informationsflüsse und Übersetzungspunkte sichtbar.
- Upstream und DownstreamUpstream gibt vor, Downstream passt sich an.
- BeziehungsmusterDas Muster benennt die Art der Zusammenarbeit.
- ÄnderungswirkungSie zeigt, wer bei einer Änderung reagiert.
Einordnung
Warum das wichtig ist
Eine Context Map zeigt, wer das Modell vorgibt und wer sich anpasst. Die Muster beschreiben, wie Teams zusammenarbeiten und wer Einfluss hat; nach Conway's Law spiegeln Systemgrenzen die Kommunikation der Organisation. Die innere Bedeutung einer einzelnen Grenze behandelt der Baustein Bounded Context.
Dieser Baustein erklärt Beziehungen zwischen Modellgrenzen. Für die innere Bedeutung einer einzelnen Grenze siehe Bounded Context.
Auf einen Blick · Kontexte und ihre Beziehungen
Wer gibt das Modell vor?
Im Shop gibt es Beziehungen innerhalb des Teams, bei denen sich Lager, Zahlung und Bestellung abstimmen. Nach außen besteht eine Beziehung zum Zahlungsanbieter, dessen Modell der Shop nicht beeinflusst.
So liest du das Bild
- Upstream und Downstream U und D an den Linienenden, etwa U am Zahlungsanbieter und D an der Zahlung.
- Beziehungsmuster Der Chip an jeder Linie: ACL, C/S (Customer/Supplier) oder PL (Published Language).
- Änderungswirkung Das Feld „Wenn … sich ändert“ nennt, was angepasst wird und was unberührt bleibt.
- Was fließt
- übersetzter Auftrag hin, Anbietercodes (APPROVED, DECLINED, PENDING_REVIEW) zurück
- Wer passt sich an
- Die Zahlung passt sich an; die ACL schirmt den Rest des Shops ab.
- Wenn Zahlungsanbieter sich ändert
- Benennt der Anbieter einen Code um, wird nur die ACL in der Zahlung angepasst; die Bestellung bleibt unberührt.
- Einfluss von Zahlung
- kein Einfluss auf den Upstream
Einordnung illustrativ
Nutzen & Grenzen
Hilft, wenn
- Mehrere fachliche Modelle arbeiten zusammen und ihre Abhängigkeiten müssen abgestimmt werden.
- Ein externer oder vorgelagerter Vertrag beeinflusst die Begriffe und Änderungen eines eigenen Bereichs.
Grenzen
- Eine Karte veraltet schnell und ist nur so gut wie ihre letzte Aktualisierung. Sie gehört zu jeder Integrationsänderung.
- In einem kleinen Team im Monolithen sind viele Muster nur schwach ausgeprägt. Am stärksten wirkt die Karte an externen Grenzen wie dem Zahlungsanbieter; dort schützt eine Anti-Corruption Layer.
In der Praxis
- Kontexte und Eigentümer erfassen. Benenne Modellgrenzen und Teams, die Daten oder Verträge verantworten. Das Ergebnis zeigt, an wen offene Integrationsfragen gerichtet werden.
- Beziehungen mit Richtung beschreiben. Halte fest, wer liefert, wer konsumiert und ob ein gemeinsames Modell oder eine Übersetzung verwendet wird. Verknüpfe die Karte mit den jeweiligen Bounded Contexts.
- Änderungsrisiken und Schutz prüfen. Markiere instabile Abhängigkeiten und kläre, wie die eigene Sprache geschützt bleibt. Eine Anti-Corruption Layer ist eine Option, wenn fremde Semantik sonst in den Fachkern gelangt.
Ausführliche Erklärung lesen
Kontexte tauschen Informationen aus und beeinflussen sich über gemeinsame Verträge, Abhängigkeiten oder Übersetzungen. Eine Context Map zeigt, wer Begriffe und Schnittstellen liefert, wer sie nutzt und wie Änderungen abgestimmt werden. Bounded Context bestimmt die beteiligten Modelle; eine Anti-Corruption Layer kann die eigene Sprache vor fremden Modellannahmen schützen.
Beziehungstyp und Richtung erklären mehr als bloße Verbindungslinien. Die Karte sollte tatsächliche Zusammenarbeit, Teamverantwortung und bekannte Risiken zeigen. Sie bleibt aktuell, wenn Verträge, Lieferanten oder organisatorische Zuständigkeiten sich ändern. Beschriftete Beziehungen machen Abhängigkeit, Einflussmöglichkeit und Übersetzungsarbeit auf der Karte erkennbar.
Bekannte Beziehungsmuster geben der Karte Namen: Ein Shared Kernel teilt einen gemeinsamen Modellteil, bei Customer/Supplier richtet der Lieferant sich nach den Bedürfnissen des Abnehmers, ein Conformist übernimmt das fremde Modell unverändert, und ein Open Host Service bietet eine offene, gepflegte Schnittstelle für viele. Der Zahlungsanbieter bestimmt sein Modell selbst; der Shop übernimmt es nicht als Conformist, sondern übersetzt es per Anti-Corruption Layer. Weitere Muster sind Partnership, bei der Teams gemeinsam planen, und Separate Ways, bei dem Kontexte bewusst nicht integriert werden.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Welche Beziehung hat der Zahlungsanbieter zur Zahlung, und wer passt sich an?
Lösung mit Begründung ansehen
Der Zahlungsanbieter ist Upstream, die Zahlung Downstream. Die Zahlung passt sich an, geschützt durch eine Anti-Corruption Layer; der Shop hat keinen Einfluss auf den Anbieter.
AnwendenAuf eine neue Lage übertragen
Der Zahlungsanbieter benennt PENDING_REVIEW um. Welche Kontexte musst du ändern?
Lösung mit Begründung ansehen
Nur die Zahlung: Die ACL übersetzt den neuen Code weiter in „Klärung läuft“. Bestellung und Rechnung kennen den Anbietercode nicht und bleiben unverändert.
BewertenEine Alternative abwägen
Das Team will die Codes des Anbieters direkt übernehmen (Conformist), um die ACL zu sparen. Wie bewertest du das?
Lösung mit Begründung ansehen
Vorteil: weniger Code und Übersetzung. Nachteil: Die Anbietercodes wandern in Bestellung und Rechnung, und jede Änderung des Anbieters trifft den ganzen Shop. Empfehlung: ACL behalten, weil der Anbieter extern ist und sein Modell selbst bestimmt.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.
Quellen
- Context Mapper · Context Map (öffnet in neuem Tab)Beschreibt Kontextbeziehungen und ihre konkrete Modellierung.
- Martin Fowler · Bounded Context (öffnet in neuem Tab)Erklärt Modellgrenzen und Beziehungen zwischen unterschiedlichen Fachmodellen.
- Eric Evans · DDD Reference (öffnet in neuem Tab)Referenz des DDD-Autors zu strategischen und taktischen Mustern.