MethodenanleitungDomain Modeling

Context Map

Die Anleitung zur Methode: Voraussetzungen und Materialien klären, den gesamten Ablauf verstehen und Ergebnisse, Stolperfallen sowie Abbruchkriterien nachschlagen.

KomplexitätMittel

Zeit1-3 h

Teilnehmende2-8

FormatWorkshop + Async

ReifegradCanonical

Planung vorbereiten

Vorbedingung

Was vorher fertig sein muss

Vorher abschließenKlare Abgrenzung

Mehrere benannte Bounded Contexts mit bekannten Modellen und mindestens einem relevanten Integrationsfluss.

Ohne Grenze werden Daten, Perspektiven oder Abläufe vermischt.

Vorher abschließenZugang zu Belegen

Relevante Personen und Quellen können einbezogen werden.

Lücken bleiben sichtbar; fehlende Evidenz darf nicht erfunden werden.

Vorbereitung

Was vor Start vorliegen muss

Materialien

Gemeinsame Arbeitsfläche, zugängliche Quellen und Notiz für Entscheidungen.

Personen / Rollen

Domain Expert:innen · Tech Leads · Facilitator

Vorabinfos

Frage, Zeitraum, Datenzugriff, beteiligte Rollen und bekannte Unsicherheiten vorab klären.

Zeitbedarf

2–4 Stunden für eine mittlere Domäne; komplexe Landschaften benötigen fokussierte Folgetermine.

Setup

Eine gemeinsame Version anlegen. Fakten, Annahmen und Entscheidung getrennt kennzeichnen.

Kernfrage

Die eine Frage, die diese Methode beantwortet

Welche Modelle gelten wo, und wie beeinflussen sich die Kontexte bei Zusammenarbeit?

Ablauf

Phasen mit Ziel, Durchführung, Ergebnis und Stolperfalle

Eine Context Map zeigt Bounded Contexts sowie ihre Integrationsbeziehungen, Abhängigkeiten und Übersetzungsgrenzen. Sie macht sichtbar, wo Modelle zusammenwirken und wo Klärungsbedarf besteht.

Kontexte, Richtung und Integrationsmuster

Fiktives Lehrbeispiel

Zeige Bounded Contexts und ihre Integrationsbeziehungen, Abhängigkeiten und Übersetzungsgrenzen.

Kontext A

Nenne Kontextgrenze, Modellverantwortung und lokale Begriffe.

Upstream: Produktbegriffe und Statuscodes.

Beziehung

Zeige Beziehung, Richtung, Schnittstelle und austauschende Information.

Downstream; ACL übersetzt externe Statuscodes in lokale Buchungsregeln.

Muster

Dokumentiere Muster, Teams und tatsächliche Kollaboration.

Publiziert BillingCompleted-Event; Buchung konsumiert es.

Klärung

Halte Mehrdeutigkeiten, Übersetzungslücken und nächste Klärung fest.

Fiktiver Befund: Status „reserviert“ bedeutet in zwei Kontexten Verschiedenes; Glossar abstimmen.

Fiktive Plattform: „Katalog“ liefert Produktdaten; „Buchung“ konsumiert sie als Upstream/Downstream-Beziehung. Ein Anti-Corruption Layer übersetzt externe Statuscodes in Buchungsbegriffe. „Abrechnung“ publiziert Events, die Buchung abonniert. Pfeile dokumentieren Richtung; sie behaupten keine Teamzuständigkeit.

Bounded Context · Martin Fowler

1
Kontexte
Kontexte und Modelle benennen
Ziel
Ist jeder Kontext intern kohärent?
Voraussetzungen für diesen Schritt
- Kontextnamen, Domänenbegriffe und Modellverantwortung
Durchführung
- Verorte Modellgrenzen anhand Sprache und Regeln; notiere Begriffe, die anderswo anders bedeuten.
- Ist jeder Kontext intern kohärent?
Ergebnis
Abgegrenzte Bounded Contexts und ihre Begriffe
Abgegrenzte Bounded Contexts und ihre Begriffe
Qualitätscheck
Ist jeder Kontext intern kohärent?
Stolperfalle
Kontextgrenzen folgen nur Systemnamen Begriffe, Regeln und Modellverantwortung als Grenzbelege heranziehen.
Zeitlicher Rahmen: Teil des vereinbarten Arbeitsblocks; Recherche ggf. separat.
2
Beziehungen
Beziehungen eintragen
Ziel
Ist Abhängigkeitsrichtung eindeutig?
Voraussetzungen für diesen Schritt
- Integrationsflüsse, APIs, Events und Datenabhängigkeit
Durchführung
- Zeichne Daten-/Prozessfluss mit Richtung und benenne Upstream/Downstream.
- Ist Abhängigkeitsrichtung eindeutig?
Ergebnis
Gerichtetes Abhängigkeits- und Integrationsbild
Gerichtetes Abhängigkeits- und Integrationsbild
Qualitätscheck
Ist Abhängigkeitsrichtung eindeutig?
Stolperfalle
Pfeilrichtung ist uneindeutig Legende für Upstream/Downstream festlegen und je Beziehung prüfen.
Zeitlicher Rahmen: Teil des vereinbarten Arbeitsblocks; Recherche ggf. separat.
3
Integration
Integrationsmuster klären
Ziel
Ist das Muster beidseitig verstanden?
Voraussetzungen für diesen Schritt
- Teambeziehung und relevante DDD-Muster
Durchführung
- Vereinbare je Beziehung Muster wie Customer-Supplier, Conformist oder ACL anhand realer Zusammenarbeit.
- Ist das Muster beidseitig verstanden?
Ergebnis
Abgestimmte Beziehungsmuster zwischen Kontexten
Abgestimmte Beziehungsmuster zwischen Kontexten
Qualitätscheck
Ist das Muster beidseitig verstanden?
Stolperfalle
Muster wird ohne Teamrealität zugewiesen Integrationsmuster mit beiden beteiligten Teams und tatsächlicher Macht-/Lieferbeziehung klären.
Zeitlicher Rahmen: Teil des vereinbarten Arbeitsblocks; Recherche ggf. separat.
4
Klärung
Reibung und nächste Entscheidung markieren
Ziel
Ist eine Landkarte als Hypothese geprüft?
Voraussetzungen für diesen Schritt
- Reibung, Übersetzung und ungelöste Grenze
Durchführung
- Kennzeichne geteilte Kernel, Übersetzung, Engpass und ungelöste Konflikte; ordne Untersuchung zu.
- Ist eine Landkarte als Hypothese geprüft?
Ergebnis
Offene Modell- und Integrationsrisiken
Offene Modell- und Integrationsrisiken
Qualitätscheck
Ist eine Landkarte als Hypothese geprüft?
Stolperfalle
Map wird als Zielarchitektur eingefroren Ist-Beziehung und gewünschte Änderung unterscheiden; Karte bei Erkenntnis aktualisieren.
Zeitlicher Rahmen: Teil des vereinbarten Arbeitsblocks; Recherche ggf. separat.

Artefakt

Was am Ende rauskommt

Skizze: so sieht das Artefakt aus

Context Map · DDD-BeziehungenBounded Contexts und ihre Integrationsbeziehungen als strategische DDD-Landkarte sichtbar machen

Form

Versioniertes Ergebnis mit Frage, Evidenz, offenen Punkten, nächster Maßnahme, Verantwortung und Reviewtermin.

Versionierung / Ownership

Datum, Geltungsbereich, Quellen und Änderungen festhalten. Frühere Beobachtungen erhalten.

Tool-Alternativen

Whiteboard oder Papier
Gemeinsame Tabelle
Projektablage mit Versionshistorie

context-map-working-template.md

Bereite Context Map mit klarer Frage, Rollen und Quellen vor.

Context Map: Arbeitsvorlage

Fragestellung

Noch zu klären

Gewünschtes Ergebnis

Noch zu klären

Rahmen

Vollständigen Ablauf planen Zeit: Nach Umfang und verfügbaren Belegen festlegen

Diese Vorlage während der Arbeit auf Papier oder in einem eigenen Dokument ausfüllen.

Vorbereitung für diesen Umfang

Methodische Grundausstattung

Materialien: Gemeinsame Arbeitsfläche, zugängliche Quellen und Notiz für Entscheidungen.
Rollen: Domain Expert:innen · Tech Leads · Facilitator
Vorab-Infos: Frage, Zeitraum, Datenzugriff, beteiligte Rollen und bekannte Unsicherheiten vorab klären.
Gesamter Zeitbedarf: 2–4 Stunden für eine mittlere Domäne; komplexe Landschaften benötigen fokussierte Folgetermine.
Setup: Eine gemeinsame Version anlegen. Fakten, Annahmen und Entscheidung getrennt kennzeichnen.

Für die Arbeitsschritte bereitstellen

Kontexte: Kontexte und Modelle benennen

Kontextnamen, Domänenbegriffe und Modellverantwortung

Beziehungen: Beziehungen eintragen

Integrationsflüsse, APIs, Events und Datenabhängigkeit

Integration: Integrationsmuster klären

Teambeziehung und relevante DDD-Muster

Klärung: Reibung und nächste Entscheidung markieren

Reibung, Übersetzung und ungelöste Grenze

Kontexte, Richtung und Integrationsmuster

Kontext A

Nenne Kontextgrenze, Modellverantwortung und lokale Begriffe.

...

Beziehung

Zeige Beziehung, Richtung, Schnittstelle und austauschende Information.

...

Muster

Dokumentiere Muster, Teams und tatsächliche Kollaboration.

...

Klärung

Halte Mehrdeutigkeiten, Übersetzungslücken und nächste Klärung fest.

...

Leere Vorlage: beginne mit einer abgegrenzten Frage. Trage nur erhobene Fakten ein, markiere Annahmen und halte offene Fragen sowie Quellen fest.

Bounded Context · Martin Fowler

Kontexte: Kontexte und Modelle benennen

Erwartetes Artefakt: Abgegrenzte Bounded Contexts und ihre Begriffe

Abgegrenzte Bounded Contexts und ihre Begriffe

Eintrag:

...

Ist jeder Kontext intern kohärent?

Beziehungen: Beziehungen eintragen

Erwartetes Artefakt: Gerichtetes Abhängigkeits- und Integrationsbild

Gerichtetes Abhängigkeits- und Integrationsbild

Eintrag:

...

Ist Abhängigkeitsrichtung eindeutig?

Integration: Integrationsmuster klären

Erwartetes Artefakt: Abgestimmte Beziehungsmuster zwischen Kontexten

Abgestimmte Beziehungsmuster zwischen Kontexten

Eintrag:

...

Ist das Muster beidseitig verstanden?

Klärung: Reibung und nächste Entscheidung markieren

Erwartetes Artefakt: Offene Modell- und Integrationsrisiken

Offene Modell- und Integrationsrisiken

Eintrag:

...

Ist eine Landkarte als Hypothese geprüft?

Offene Fragen und nächste Schritte

...

Methodenanleitung: https://methodatlas.meierhoff-systems.de/de/methods/context-map/run-sheet

Beispielausgabe

Konkret gefülltes Szenario, fiktives Beispiel

Fiktives Beispiel zur Orientierung. Die genannten Mengen und Zeiten beschreiben diesen Fall und sind keine allgemeine Vorgabe.

context-map-beispiel.md

Konkret gefülltes Szenario, fiktives Beispiel

Fiktives Lehrbeispiel

Alle Namen und Werte sind erfunden und dienen nur der Illustration. Offene Erklärungen bleiben als Fragen markiert.

Stolperfallen

Symptome erkennen, gegensteuern

Kurzüberblick, vollständiger Text steht in der jeweiligen Phase im Ablauf

Kontexte und Modelle benennenKontextgrenzen folgen nur SystemnamenIn der Phase ansehen
Beziehungen eintragenPfeilrichtung ist uneindeutigIn der Phase ansehen
Integrationsmuster klärenMuster wird ohne Teamrealität zugewiesenIn der Phase ansehen
Reibung und nächste Entscheidung markierenMap wird als Zielarchitektur eingefrorenIn der Phase ansehen