Run SheetDomain ModelingDomain Landscape

Domain Context Map

KomplexitätMedium

Zeit1-3 h

Teilnehmende3-10

FormatWorkshop

MaturityEstablished

Vorbedingung

Was vorher fertig sein muss

Vorher abschließenEvent Storming

Ein Big-Picture-Event-Storming oder vergleichbares Domain-Discovery-Artefakt liegt vor, aus dem Bounded Contexts ableitbar sind.

Ohne: Ohne Domain-Verständnis wird die Context Map zu einer Architekturskizze auf technischer Ebene, ohne fachliche Trennlinien.

Vorher abschließenDomain Storytelling

Mindestens eine erzählte Domain-Geschichte mit Akteuren, Arbeitsobjekten und Übergaben existiert, aus der Kontextgrenzen sichtbar werden.

Ohne: Ohne narrative Vorarbeit fehlen Belege für Boundary-Entscheidungen, Map wird Vermutung statt Modell.

Vorbereitung

Was vor Start vorliegen muss

Materialien

Whiteboard oder Miro mit Bereich für Boxes (Bounded Contexts), Pfeile (Beziehungen) und Legende für Beziehungstypen (Shared Kernel, Customer/Supplier, Conformist, ACL, OHS, Published Language, Partnership); Liste bekannter Subdomänen; Owner-Liste.

Personen / Rollen

Ein Architect oder Domain Modeler als Facilitator; 3-10 Teilnehmende aus Engineering und Domain (Owner pro Context); ein Scribe für Boundary-Notes; ein Decider bei Streitfällen.

Vorabinfos

Existierende Service-Landschaft (Dokumentation, Repo-Liste); Subdomänen aus Domain Discovery; Team-Topologie und Ownership-Daten; bekannte Schnittstellen-Probleme aus den letzten Monaten.

Zeitbedarf

1-3 h

Setup

Drei Phasen-Bereiche an die Wand: Contexts, Beziehungen, Hot Spots. Legende der DDD-Beziehungstypen sichtbar. Regel: Map zeigt fachliche Grenzen, nicht Repository-Struktur.

Kernfrage

Die eine Frage, die diese Methode beantwortet

Welche Bounded Contexts und welche Beziehungen zwischen ihnen prägen die Domain-Landschaft heute, und wo entstehen die größten Reibungspunkte?

Ablauf

Marker: Phase

Schritt	Dauer	Aktion	Hinweis
1Phase 1: Contexts identifizieren	30-45 min	Bounded Contexts oder Subdomänen als Boxes an die Wand kleben. Pro Box: Name, Owner-Team, kurzer Zweck. Subdomain-Typ markieren (Core, Supporting, Generic).	Wenn 20+ Contexts entstehen, sind sie zu fein geschnitten oder Subdomänen werden mit Microservices verwechselt. Lieber 6-12 fachliche Contexts.
2Phase 2: Beziehungen einzeichnen	30-60 min	Zwischen Context-Paaren Pfeile ziehen, mit Beziehungstyp beschriften (z. B. Customer/Supplier mit Upstream/Downstream, Conformist, ACL, Shared Kernel). Bei Unklarheit Pfeil mit Fragezeichen.	Beziehungstyp ist nicht Datenflussrichtung, sondern Machtverhältnis und Übersetzungsbedarf. Wer das verwechselt, baut falsche Schutzschichten.
3Phase 3: Hot Spots markieren	20-30 min	Pink-Notes an Beziehungen mit Reibung: häufige Bugs, unklare Verantwortung, semantische Konflikte. Auch unbenutzte Beziehungen markieren (potenziell tote Integration).	Hot Spots sind wertvoller Output. Mindestens 3-5 erwartbar, sonst war die Diskussion zu höflich. Konkrete Vorfälle nennen, nicht abstrakte Befürchtungen.
4Phase 4: Implikationen und Aktionen	20-30 min	Pro Hot Spot Owner und Folgeaktion festlegen (Spike, ADR, Schnittstellen-Review). Mindestens drei Aktionen mit Datum. Map fotografieren und versionieren.	Map ohne Aktionen wird Dekoration. Folge-Termin in 4-6 Wochen, um Aktionen und Veränderungen zu reviewen.

Artefakt

Was am Ende rauskommt

Form

Reingezeichnete Context Map als SVG oder Diagramm-Datei mit Boxes pro Bounded Context (Name, Owner, Typ), Pfeilen mit Beziehungstypen, markierten Hot Spots, einer Tabelle der Beziehungen mit Beschreibung und Liste der nächsten Aktionen mit Owner und Datum.

Tool-Alternativen

Miro oder FigJam mit DDD-Context-Map-Template
Structurizr DSL oder C4-Modell-Tools
draw.io oder Lucidchart mit Versionierung
Mermaid in Markdown im Architektur-Repo

Versionierung / Ownership

Pro Edition Datum und Version. Vorherige Map behalten. Veränderungen (neue Contexts, geänderte Beziehungen, gelöste Hot Spots) als Delta markieren. Mindestens halbjährliche Reviews.

canvas

Domain Context Map Arbeitsvorlage

Kompakte Arbeitsvorlage für Domain Context Map mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.

# Domain Context Map Canvas

## Kontext

Wofür wird die Methode eingesetzt?

## Kernfrage

Welche Frage soll am Ende beantwortet sein?

## Input

Welche Daten, Beobachtungen oder Materialien liegen vor?

## Arbeitsfläche

- Bereich 1:
- Bereich 2:
- Bereich 3:
- Beziehungen / Muster:

## Ergebnisartefakte
- Domain Context Map:
- Boundary Notes:
- Ownership Map:

## Offene Fragen

- ...

## Nächster Schritt

Owner, Datum, Erfolgssignal.

Beispielausgabe

Konkret gefülltes Szenario

domain-context-map-beispiel.md

markdown

## Context Map — Order Fulfillment Domain, 12.05.2026

**Contexts**
- Ordering (Core, Team A): Auftragsentgegennahme, Validierung, Reservierung.
- Payment (Supporting, Team B): Zahlungsautorisierung, Refunds. Externer PSP via Webhook.
- Inventory (Core, Team C): Bestandsführung, Reservierungen, Verfügbarkeit.
- Shipping (Supporting, Team D): Versand-Erstellung, Tracking-Push.
- Returns (Supporting, Team A): Rücksendungs-Workflow.
- Customer (Generic, Team E): Adressen, Stammdaten, Konsentmanagement.

**Beziehungen**
- Ordering -> Payment: Customer/Supplier, Upstream Payment. ACL in Ordering, weil Payment-API instabil.
- Ordering -> Inventory: Partnership. Geteilter Reservierungs-Lifecycle.
- Ordering -> Shipping: Customer/Supplier, Upstream Ordering. Published Language via Kafka-Topic `orders.v3`.
- Returns <-> Ordering: Shared Kernel (Order-Aggregat). Ursprung des Hot Spot #2.
- Customer -> alle: Conformist (Stammdaten unverändert übernommen).

**Hot Spots**
- Pink #1: Ordering<->Payment-ACL ist veraltet, PSP hat neue Felder eingeführt. Owner: @anna, ADR bis 30.05.
- Pink #2: Returns/Ordering Shared Kernel führt regelmäßig zu Merge-Konflikten und Deployment-Koordination. Owner: @lisa, Separations-Spike bis 14.06.
- Pink #3: Inventory-Partnership ohne klares Konfliktlösungs-Protokoll bei Race Conditions. Owner: @ben, RFC bis 21.05.

**Folge-Review**: 30.06.2026.

Was tun

Pro Hot Spot eine ADR-, RFC- oder Spike-Aktion mit Owner und Datum. Folge-Review-Termin fest planen, nicht „bei Gelegenheit“.

Abbruchkriterien

Done-Signale, in unter einer Minute prüfbar

Keine Domain-Vorarbeit (Event Storming, Domain Storytelling), Contexts werden Rateversuche.

Owner-Verantwortung für Contexts ist nicht klärbar, Map bleibt politisch.

Architektur ist im großen Refactoring, Map wäre nach Wochen veraltet.

Organisation ist zu klein (1 Service, 1 Team), Kontextkonzept hat keinen Mehrwert.

Map wird nur als Compliance-Artefakt verlangt, kein Team will damit arbeiten.

DDD-Vokabular ist im Team unbekannt, Workshop verlangt zuerst Schulung, kein direkter Mehrwert.

Run Sheet durchgearbeitet?

Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.

Zum Steckbrief Weitere Methoden