Domain Modeling Mapping Tool

Domain Context Map

Eine Domain Context Map zeigt, wo bestimmte Modelle gelten und wie ihre verantwortlichen Teams zusammenarbeiten müssen.

Eine Context Map zeigt Bounded Contexts mit eigener Fachsprache und Modellverantwortung sowie ihre Integrations- und Teambeziehungen. Upstream und Downstream beschreiben Modellabhängigkeit; das ist nicht automatisch die Richtung eines Datenpakets.

Kernfrage

Wo gelten welche Modelle und wie müssen ihre verantwortlichen Teams zusammenarbeiten?

Planen Methodenanleitung

Vergleich starten

Feedback gebenHilft dir diese Methode?

Teilnehmende: 3-10 Beteiligte
Zeit: 90–180 Minuten erster Ausschnitt; weitere Modellierungstermine nach Bedarf

Papierillustration zu Domain Context Map

Contexts
Contexts abgrenzen
Anhand von Begriffen und Regeln Bereiche mit jeweils konsistentem Modell identifizieren.
Ownership
Ownership und Ist-Bild
Jeden Context einem verantwortlichen Team zuordnen und bestehende Integrationen sammeln.
Abhängigkeit
Abhängigkeiten beschriften
Für jedes verbundene Paar Modellabhängigkeit als Upstream/Downstream oder symmetrische Beziehung bestimmen.
Muster
Beziehungsmuster prüfen
Teambeziehung und Integrationsmuster begründet wählen: etwa Customer/Supplier, Partnership, Conformist oder Anti-Corruption Layer.
Risiken
Risiken und nächste Modellierung
Widersprüchliche Begriffe, ungepflegte Verträge und starke Kopplungen mit beiden Seiten prüfen.

Bei Modell-, Team- oder Vertragsänderungen Beziehungen mit beiden Seiten prüfen und Map versionieren.

Geeignet, wenn

Für Domain-Driven Design, wenn Modellgrenzen oder teamübergreifende Integrationen geklärt werden müssen.

Ideal für

DDD Strategy
Architecture Discovery
Platform Boundaries

Nicht gut für

Story-level Refinement
UI Flow Design

Ergebnisse

Context Map mit Modellbeziehungen
Die versionierte Context Map enthält Grenzen, Fachbegriffe, Owner, gerichtete Abhängigkeiten, Beziehungsmuster und offene Modellierungsfragen.
Geprüfte Map und Klärungsaufträge
Der Klärungsauftrag enthält eine konkrete Modellierungs- oder Vertragsfrage mit Owner und Termin.

Domain Context Map · Arbeitsvorlage

Fiktives Beispiel

Context-Inventar

Pro Context Zweck, Fachbegriffe, Grenzen und Owner erfassen.

Fiktiv: Catalog (Team Angebot) verwaltet Kursangebote; Enrollment (Team Teilnahme) verwaltet Platzreservierungen; Billing (Team Finanzen) verwaltet Forderungen.

Beziehung 1

Contexts, U/D-Rollen, Vertrag, Muster und Änderungsabstimmung notieren.

Catalog U → Enrollment D: Kurs-ID und Angebot über versionierte API. Catalog bietet OHS/Published Language; Enrollment übersetzt fremde Statuswerte per ACL in sein Reservierungsmodell.

Beziehung 2

Eine weitere Beziehung einschließlich Einfluss auf die Schnittstelle beschreiben.

Enrollment U → Billing D: bestätigte Anmeldung als Ereignis. Customer/Supplier: Billing kann benötigte Abrechnungsfelder mit Team Teilnahme vereinbaren.

Offene Modellierungsfrage

Welche Bedeutung oder Verantwortung ist ungeklärt, wer klärt sie und womit?

Bei Stornierung unterscheiden sich Reservierungsstatus und Forderungsstatus. Beide Teams prüfen bis Freitag drei Stornofälle und dokumentieren die Ereignisregeln.

Alle Beispielangaben sind erfunden; sie erläutern die Anwendung.

DDD Crew: Context Mapping

Erster Schritt

Einen fachlichen Ausschnitt, konkrete Geschäftsabläufe, Teamzuständigkeiten und bekannte Schnittstellen zusammentragen. Ist- und Zielbild getrennt betrachten.

Zur Methodenanleitung

Davor sinnvoll

Domain Modeling

EventStorming

Liefert Domainevents und Begriffe als Grundlage für die Context Map.

Wie geht es weiter?

Domain Modeling

Bounded Context Canvas

Konkretisiert einen Klärungsauftrag zu einem ausformulierten Bounded Context.

Knowledge Modeling

Domain Storytelling

Vertieft ein geklärtes Modellgebiet mit erzählten Abläufen.

Vertiefung

Zweck

Wenn ein Domänenmodell und die dazugehörigen Kontexte zusammen gedacht werden sollen, schafft sie einen gemeinsamen Überblick. Sie verbindet fachliche Sicht und organisatorische Grenze zu einem lesbaren Ganzen.

Funktionsweise

Sie stellt Domänenbestandteile und Kontextgrenzen nebeneinander und macht ihre Verknüpfung explizit. Dadurch werden Modell, Zusammenarbeit und Integrationspunkte gemeinsam diskutierbar, ohne fachliche Grenze und technische Schnittstelle zu vermischen.

Im Detail

Diese Methode trägt, weil sie fachliche Räume aus Sicht der Domäne ordnet und dadurch eine robustere Grundlage für spätere Team oder Systemzuschnitte schafft. Gute Anwendung schaut auf Sinnzusammenhang, Sprachgrenzen und Wechselwirkungen, statt bestehende Organigramme nur neu zu beschriften. So entsteht ein Bild, das strategische Abgrenzung ermöglicht und zugleich offenlegt, wo gemeinsame Begriffe nur scheinbar dieselbe Bedeutung haben.

Durchführung

Nimm Fälle mit, bei denen ähnliche Begriffe in verschiedenen Bereichen andere Folgen auslösen, denn daran zeigen sich die Trennlinien am klarsten. Richtig ergiebig wird es, wenn ein Begriff stabil bleibt, aber der Zweck wechselt. Schließe mit einer kurzen Liste benannter Kontexte und den unsichersten Übergängen zwischen ihnen.

Die Methodenanleitung führt mit 5 Phasen, Zeitrahmen, 5 Stolperfallen und klaren Abbruchkriterien durch die Umsetzung.

Methodenanleitung öffnen

Deine Einschätzung

Hilft dir diese Methode für dein Vorhaben?

Mit deinem Feedback hilfst du, den Methodatlas weiterzuentwickeln.

Quellen und Themen

Themen

Domain-Driven Design Kontext Grenzen

Quellen

DDD Crew: Context Mappinggithub.comPrimäres Community-Arbeitsmaterial zu Bounded Contexts und Beziehungsmustern; Beispiel redaktionell.

Artefakt-Vorlagen

Domain Context Map: ArbeitsvorlageEinen fachlichen Ausschnitt, konkrete Geschäftsabläufe, Teamzuständigkeiten und bekannte Schnittstellen zusammentragen. Ist- und Zielbild getrennt betrachten.

markdown

domain-context-map-working-template.md

Einen fachlichen Ausschnitt, konkrete Geschäftsabläufe, Teamzuständigkeiten und bekannte Schnittstellen zusammentragen. Ist- und Zielbild getrennt betrachten.

Domain Context Map: Arbeitsvorlage

Fragestellung

Noch zu klären

Gewünschtes Ergebnis

Noch zu klären

Rahmen

Gesamter Durchlauf Zeit: 90–180 Minuten erster Ausschnitt; weitere Modellierungstermine nach Bedarf

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

Vorbereitung für diesen Umfang

Methodische Grundausstattung

Materialien: Context-Karten, Integrationsverträge, Teamliste, Pfeile mit U/D-Legende und Notizen zu Fachbegriffen.
Rollen: Domänenfachleute, Modellverantwortliche, beteiligte Entwicklungsteams und Moderation.
Vorab-Infos: Einen fachlichen Ausschnitt, konkrete Geschäftsabläufe, Teamzuständigkeiten und bekannte Schnittstellen zusammentragen. Ist- und Zielbild getrennt betrachten.
Gesamter Zeitbedarf: 90–180 Minuten erster Ausschnitt; weitere Modellierungstermine nach Bedarf
Setup: Context-Karten mit Fachbegriffen und Ownern auslegen; U/D-Legende ergänzen und Verbindungen aus konkreten Integrationen ableiten.