Vorher abschließenDomänenwissen
Fachkundige können Begriffe und Geschäftsregeln anhand realer Abläufe erklären.
Ohne Fachsprache entstehen leicht reine Systemkästen.
MethodenanleitungDomain Modeling
Domain 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
Teilnehmende3-10
FormatWorkshop
ReifegradEstablished
01
Vorbedingung
Was vorher fertig sein muss
Vorher abschließenBeide Seiten
Vertretungen der beteiligten Teams können Abhängigkeiten und Einflussmöglichkeiten bestätigen.
Einseitige Annahmen als ungeklärt markieren.
02
Vorbereitung
Was vor Start vorliegen muss
Materialien
Context-Karten, Integrationsverträge, Teamliste, Pfeile mit U/D-Legende und Notizen zu Fachbegriffen.
Personen / Rollen
Domänenfachleute, Modellverantwortliche, beteiligte Entwicklungsteams und Moderation.
Vorabinfos
Einen fachlichen Ausschnitt, konkrete Geschäftsabläufe, Teamzuständigkeiten und bekannte Schnittstellen zusammentragen. Ist- und Zielbild getrennt betrachten.
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.
03
Kernfrage
Die eine Frage, die diese Methode beantwortet
Wo gelten welche Modelle und wie müssen ihre verantwortlichen Teams zusammenarbeiten?
04
Ablauf
Phasen mit Ziel, Durchführung, Ergebnis und Stolperfalle
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.
Domain Context Map · Arbeitsvorlage
Fiktives Beispiel
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.
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.
- 1
Contexts
Contexts abgrenzen
Ziel
Context-Inventar
Voraussetzungen für diesen Schritt
- Geschäftsabläufe
- Begriffe und Regeln
Durchführung
- Anhand von Begriffen und Regeln Bereiche mit jeweils konsistentem Modell identifizieren.
- Für jeden Context Verantwortung, Kernbegriffe und Grenzen notieren; Subdomäne und Deployment nicht gleichsetzen.
Ergebnis
Context-Inventar
Gilt innerhalb jeder Grenze eine konsistente Fachsprache?
Qualitätscheck
Gilt innerhalb jeder Grenze eine konsistente Fachsprache?
Stolperfalle
Jeder Microservice wird ohne Prüfung zum Bounded Context. Modellbedeutungen vergleichen und Grenzen fachlich begründen.
Zeitlicher Rahmen: 20–40 Minuten
- 2
Ownership
Ownership und Ist-Bild
Ziel
Bestätigte Zuständigkeiten
Voraussetzungen für diesen Schritt
- Context-Inventar
- Teamvertreter
Durchführung
- Jeden Context einem verantwortlichen Team zuordnen und bestehende Integrationen sammeln.
- Tatsächlichen Zustand und gewünschte Zukunft mit getrennten Versionen markieren.
Ergebnis
Bestätigte Zuständigkeiten
Sind Owner und Ist-Status für jeden Context bestätigt?
Qualitätscheck
Sind Owner und Ist-Status für jeden Context bestätigt?
Stolperfalle
Wunscharchitektur verdeckt heutige Abhängigkeiten. Zuerst die tatsächlich genutzten Verträge und Zuständigkeiten abbilden.
Zeitlicher Rahmen: 15–25 Minuten
- 3
Abhängigkeit
Abhängigkeiten beschriften
Ziel
Beschriftete Context-Beziehungen
Voraussetzungen für diesen Schritt
- Integrationen
- Modellabhängigkeiten
Durchführung
- Für jedes verbundene Paar Modellabhängigkeit als Upstream/Downstream oder symmetrische Beziehung bestimmen.
- Fachlichen Austausch und Vertragsgrenze direkt an der Verbindung benennen.
Ergebnis
Beschriftete Context-Beziehungen
Ist die Pfeilbedeutung in einer Legende erklärt?
Qualitätscheck
Ist die Pfeilbedeutung in einer Legende erklärt?
Stolperfalle
Datenfluss und Einflussrichtung werden verwechselt. Beide Perspektiven getrennt beschriften und mit den Teams abgleichen.
Zeitlicher Rahmen: 20–35 Minuten
- 4
Muster
Beziehungsmuster prüfen
Ziel
Begründete Beziehungsmuster
Voraussetzungen für diesen Schritt
- Context-Beziehungen
- Teamvereinbarungen
Durchführung
- Teambeziehung und Integrationsmuster begründet wählen: etwa Customer/Supplier, Partnership, Conformist oder Anti-Corruption Layer.
- Shared Kernel nur mit gemeinsamer Änderungspflege festhalten; offene Annahmen markieren.
Ergebnis
Begründete Beziehungsmuster
Beschreibt das Muster tatsächliche Zusammenarbeit und Übersetzung?
Qualitätscheck
Beschreibt das Muster tatsächliche Zusammenarbeit und Übersetzung?
Stolperfalle
Muster werden dekorative Etiketten ohne Vereinbarung. Für jedes Muster Konsequenzen für Änderungen, Übersetzung und Abstimmung klären.
Zeitlicher Rahmen: 20–40 Minuten
- 5
Risiken
Risiken und nächste Modellierung
Ziel
Geprüfte Map und Klärungsaufträge
Voraussetzungen für diesen Schritt
- Map-Entwurf
- Konkrete Geschäftsfälle
Durchführung
- Widersprüchliche Begriffe, ungepflegte Verträge und starke Kopplungen mit beiden Seiten prüfen.
- Einen konkreten Modellierungs- oder Vertragsklärungsauftrag samt Owner und Termin vereinbaren.
Ergebnis
Geprüfte Map und Klärungsaufträge
Sind ungeklärte Beziehungen mit einem Klärungsauftrag verbunden?
Qualitätscheck
Sind ungeklärte Beziehungen mit einem Klärungsauftrag verbunden?
Stolperfalle
Aus der Map folgt sofort ein großer Umbau. Zunächst die risikoreichste Annahme anhand eines Geschäftsfalls prüfen.
Zeitlicher Rahmen: 15–30 Minuten
05
Artefakt
Was am Ende rauskommt
Skizze: so sieht das Artefakt aus
Form
Versionierte Context Map mit Grenzen, Fachbegriffen, Ownern, gerichteten Abhängigkeiten, Beziehungsmustern und offenen Modellierungsfragen.
Versionierung / Ownership
Datum und Geltungsbereich festhalten; bei Änderungen den alten Stand mit Begründung erhalten.
Tool-Alternativen
- Whiteboard mit Context-Karten
- Versionierte Diagrammdatei
- Context Mapper oder Textdokument
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.
Für die Arbeitsschritte bereitstellen
Contexts: Contexts abgrenzen
- Geschäftsabläufe
- Begriffe und Regeln
Ownership: Ownership und Ist-Bild
- Context-Inventar
- Teamvertreter
Abhängigkeit: Abhängigkeiten beschriften
- Integrationen
- Modellabhängigkeiten
Muster: Beziehungsmuster prüfen
- Context-Beziehungen
- Teamvereinbarungen
Risiken: Risiken und nächste Modellierung
- Map-Entwurf
- Konkrete Geschäftsfälle
Domain Context Map · Arbeitsvorlage
Context-Inventar
Pro Context Zweck, Fachbegriffe, Grenzen und Owner erfassen.
...
Beziehung 1
Contexts, U/D-Rollen, Vertrag, Muster und Änderungsabstimmung notieren.
...
Beziehung 2
Eine weitere Beziehung einschließlich Einfluss auf die Schnittstelle beschreiben.
...
Offene Modellierungsfrage
Welche Bedeutung oder Verantwortung ist ungeklärt, wer klärt sie und womit?
...
Arbeitsimpulse mit eigenen Angaben beantworten. Unbekanntes und Annahmen ausdrücklich markieren.
Contexts: Contexts abgrenzen
Erwartetes Artefakt: Context-Inventar
Gilt innerhalb jeder Grenze eine konsistente Fachsprache?
Eintrag:
...
- Gilt innerhalb jeder Grenze eine konsistente Fachsprache?
Ownership: Ownership und Ist-Bild
Erwartetes Artefakt: Bestätigte Zuständigkeiten
Sind Owner und Ist-Status für jeden Context bestätigt?
Eintrag:
...
- Sind Owner und Ist-Status für jeden Context bestätigt?
Abhängigkeit: Abhängigkeiten beschriften
Erwartetes Artefakt: Beschriftete Context-Beziehungen
Ist die Pfeilbedeutung in einer Legende erklärt?
Eintrag:
...
- Ist die Pfeilbedeutung in einer Legende erklärt?
Muster: Beziehungsmuster prüfen
Erwartetes Artefakt: Begründete Beziehungsmuster
Beschreibt das Muster tatsächliche Zusammenarbeit und Übersetzung?
Eintrag:
...
- Beschreibt das Muster tatsächliche Zusammenarbeit und Übersetzung?
Risiken: Risiken und nächste Modellierung
Erwartetes Artefakt: Geprüfte Map und Klärungsaufträge
Sind ungeklärte Beziehungen mit einem Klärungsauftrag verbunden?
Eintrag:
...
- Sind ungeklärte Beziehungen mit einem Klärungsauftrag verbunden?
Offene Fragen und nächste Schritte
...
Methodenanleitung: https://methodatlas.meierhoff-systems.de/de/methods/domain-context-map/run-sheet
06
Beispielausgabe
Konkret gefülltes Szenario, fiktives Beispiel
Fiktives Beispiel zur Orientierung. Die genannten Mengen und Zeiten beschreiben diesen Fall und sind keine allgemeine Vorgabe.
domain-context-map-beispiel.md
Konkret gefülltes Szenario, fiktives Beispiel
Fiktives Beispiel
Context-Inventar: Fiktiv: Catalog (Team Angebot) verwaltet Kursangebote; Enrollment (Team Teilnahme) verwaltet Platzreservierungen; Billing (Team Finanzen) verwaltet Forderungen.
Beziehung 1: 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: Enrollment U → Billing D: bestätigte Anmeldung als Ereignis. Customer/Supplier: Billing kann benötigte Abrechnungsfelder mit Team Teilnahme vereinbaren.
Offene Modellierungsfrage: Bei Stornierung unterscheiden sich Reservierungsstatus und Forderungsstatus. Beide Teams prüfen bis Freitag drei Stornofälle und dokumentieren die Ereignisregeln.
07
Stolperfallen
Symptome erkennen, gegensteuern
Kurzüberblick, vollständiger Text steht in der jeweiligen Phase im Ablauf
- Contexts abgrenzenJeder Microservice wird ohne Prüfung zum Bounded Context.In der Phase ansehen
- Ownership und Ist-BildWunscharchitektur verdeckt heutige Abhängigkeiten.In der Phase ansehen
- Abhängigkeiten beschriftenDatenfluss und Einflussrichtung werden verwechselt.In der Phase ansehen
- Beziehungsmuster prüfenMuster werden dekorative Etiketten ohne Vereinbarung.In der Phase ansehen
- Risiken und nächste ModellierungAus der Map folgt sofort ein großer Umbau.In der Phase ansehen
Falle
Contexts abgrenzen
Symptom
Jeder Microservice wird ohne Prüfung zum Bounded Context.
Was tun
Modellbedeutungen vergleichen und Grenzen fachlich begründen.
Falle
Ownership und Ist-Bild
Symptom
Wunscharchitektur verdeckt heutige Abhängigkeiten.
Was tun
Zuerst die tatsächlich genutzten Verträge und Zuständigkeiten abbilden.
Falle
Abhängigkeiten beschriften
Symptom
Datenfluss und Einflussrichtung werden verwechselt.
Was tun
Beide Perspektiven getrennt beschriften und mit den Teams abgleichen.
Falle
Beziehungsmuster prüfen
Symptom
Muster werden dekorative Etiketten ohne Vereinbarung.
Was tun
Für jedes Muster Konsequenzen für Änderungen, Übersetzung und Abstimmung klären.
Falle
Risiken und nächste Modellierung
Symptom
Aus der Map folgt sofort ein großer Umbau.
Was tun
Zunächst die risikoreichste Annahme anhand eines Geschäftsfalls prüfen.
08
Abbruchkriterien
Wann du anhalten, Voraussetzungen klären oder einen anderen Ansatz wählen solltest
Ungeklärte Grenzen oder fehlende Teamvertretung als Hypothese markieren; daraus keine verbindliche Schnittstellenverpflichtung ableiten.
Methodenanleitung durchgearbeitet?
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen oder direkt zur nächsten Methode im Katalog.