Run SheetDomain ModelingStrategic DDD

Context Map

KomplexitätMedium

Zeit1-3 h

Teilnehmende2-8

FormatBoth

MaturityCanonical

Vorbedingung

Was vorher fertig sein muss

Vorher abschließenEvent Storming

Mindestens ein Big-Picture Event Storming hat stattgefunden, sodass Bounded Contexts als Boundaries-Kandidaten existieren.

Ohne: Ohne Bounded Contexts als Eingabe wird die Context Map zur architektonischen Wunschliste ohne Bezug zur Domain.

Vorher abschließenBounded Context Canvas

Fuer mindestens drei Bounded Contexts liegen Canvas mit Verantwortlichkeiten und ubiquitous Language vor.

Ohne: Ohne Context-Verstaendnis bleibt die Mapping-Diskussion oberflaechlich und Integrationsmuster werden nicht passgenau gewaehlt.

Vorbereitung

Was vor Start vorliegen muss

Materialien

Whiteboard oder Miro-Board mit Platz fuer 5-15 Contexts; Symbol-Set fuer DDD-Beziehungsmuster (Partnership, Shared Kernel, Customer-Supplier, Conformist, Anti-Corruption Layer, Open Host Service, Published Language, Big Ball of Mud); Beziehungslinien mit Richtung; Notiz-Stickies fuer Pain Points.

Personen / Rollen

Ein DDD-erfahrener Facilitator; Architekt(en) mit Systemueberblick; Tech Lead pro Context; Product Owner pro Context; ein Scribe.

Vorabinfos

Liste der bekannten Bounded Contexts mit Kurzbeschreibung; bestehende Integrationen (API, Events, Datenbanken); bekannte Schmerzpunkte (Doppelarbeit, Inkonsistenzen, lange Releases); Team-Org pro Context.

Zeitbedarf

3-4 h fuer mittlere Domains, 1 Tag fuer komplexe

Setup

Contexts als Kreise auf der Wand. Legende mit Mustern sichtbar. Regel ansagen: Beziehungen sind asymmetrisch, Pfeil zeigt von Downstream zu Upstream (Abhaengigkeit).

Kernfrage

Die eine Frage, die diese Methode beantwortet

Welche Bounded Contexts existieren, wie sind sie integriert, wo entstehen Reibung und Modellverfaelschung, und welche Beziehungsmuster sind angemessen?

Ablauf

Marker: Phase

Schritt	Dauer	Aktion	Hinweis
1Phase 1: Contexts inventarisieren	30 min	Alle bekannten Bounded Contexts als Kreise auf der Wand. Pro Context Owner-Team und Kurz-Verantwortung. Doppelung oder Ueberlappung explizit kennzeichnen.	Wenn 25 Contexts entstehen, ist die Granularitaet zu fein. Auf strategische Ebene fokussieren, technische Module nicht als eigene Contexts auffuehren.
2Phase 2: Beziehungen identifizieren	60 min	Pro Context-Paar fragen: gibt es eine Beziehung (Daten, Events, API). Wenn ja, Pfeil zeichnen (Upstream-Downstream). Beziehungsstaerke und -art notieren.	Wenn alle Contexts mit allen verbunden sind, ist die Modularisierung gescheitert oder die Map zu grob. Beides sichtbar machen und nicht uebermalen.
3Phase 3: Muster zuordnen	60 min	Pro Beziehung passendes Muster waehlen: Partnership (gleichberechtigt), Shared Kernel (gemeinsamer Code), Customer-Supplier (Downstream verhandelt), Conformist (Downstream akzeptiert), ACL (Downstream schuetzt sich), Open Host Service, Published Language, Big Ball of Mud (Anti-Pattern).	Muster sind nicht Wunsch, sondern Diagnose. Wenn aktuelle Realitaet Big Ball of Mud ist, das ehrlich kennzeichnen. Zielmuster separat notieren.
4Phase 4: Pain Points und Zielzustand	45 min	Pain Points an Beziehungen markieren (lange Releases, Bug-Risiken, Doppel-Modelle). Pro Top-3-Pain einen Ziel-Beziehungstyp definieren und Massnahmen.	Zielzustand ist nicht 100% sauber, sondern eine pragmatische Verbesserung in 6-12 Monaten. ACL einfuehren ist haeufig erster Schritt.
5Phase 5: Strategy und Followups	30 min	Strategische Konsequenzen ableiten: welche Teams uebernehmen welche Beziehung, welche Refactorings noetig, welche Plattform-Faehigkeiten fehlen. Top-3-Massnahmen mit Owner und Frist.	Context Map ohne Folgeaktionen ist Diagramm-Tourismus. Mindestens drei Massnahmen mit Erfolgsindikator und 3-Monats-Frist.

Artefakt

Was am Ende rauskommt

Form

Context Map als Diagramm mit Contexts, Beziehungen und Mustern, plus Tabelle mit Pain Points, Zielmustern und Massnahmen. Ergaenzt um Team-Zuordnung und Hinweise auf ADRs.

Tool-Alternativen

Miro oder Lucidchart mit DDD-Template
draw.io mit Strategic Design Stencils
Structurizr mit eingebauten DDD-Notationen
Markdown plus Mermaid-Diagramm im Architekturordner
Context Mapper (DSL-basiert, contextmapper.org)

Versionierung / Ownership

Pro Iteration eine Version mit Datum. Vorgaengerversion archivieren, Aenderungen am Beziehungstyp mit Begruendung dokumentieren. Verknuepfung zu ADRs pflicht.

canvas

Context Map Arbeitsvorlage

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

# 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
- Context Map:
- Integration Patterns:
- Boundary Notes:

## Offene Fragen

- ...

## Nächster Schritt

Owner, Datum, Erfolgssignal.

Beispielausgabe

Konkret gefülltes Szenario

context-map-beispiel.md

markdown

## Context Map - Workspot Plattform, Mai 2026

**Contexts (Auszug)**
- Ordering (Team Booking)
- Payment (Team Money)
- Inventory (Team Spaces)
- Identity (Team Platform)
- Customer Communication (Team Growth)
- Billing (Team Money, Conformist auf externes ERP)

**Beziehungen**
- Ordering -> Payment: Customer-Supplier mit Open Host Service (REST). Ordering ist Downstream, Payment definiert API.
- Ordering -> Inventory: Partnership (beide Teams gleichberechtigt, gemeinsame Modellsprache fuer Reservierung).
- Ordering -> Identity: Conformist (Ordering nutzt Identity-User-Model unveraendert).
- Billing -> ERP (extern): ACL eingebaut, schuetzt eigenes Domain-Modell.
- Customer Communication -> Ordering: Published Language (Event-Stream BookingPlaced als Vertrag).

**Pain Points**
- Ordering und Inventory haben divergente Modelle von „Stock“, Inkonsistenzen taeglich. Aktuell Big Ball of Mud, Ziel Partnership mit Shared Kernel fuer Stock-Aggregat.
- Billing-ACL leckt: ERP-spezifische Felder tauchen im eigenen Modell auf.

**Top-Massnahmen**
- CM-01: Stock-Aggregat als Shared Kernel definieren. Owner: @lisa (Spaces) und @ben (Booking), bis 31.07.
- CM-02: Billing-ACL refaktorieren, Modell-Eingang ueber Mapper saeubern. Owner: @anna, bis 30.06.
- CM-03: Customer-Communication-Vertrag (Event-Schema) versionieren. Owner: @marcus, bis 15.06.

Was tun

ACL nur bei tatsaechlichem Modellschutz noetig. Wenn beide Seiten harmonieren, einfacher Open Host Service oder Partnership.

Abbruchkriterien

Done-Signale, in unter einer Minute prüfbar

Keine Bounded Contexts identifiziert, EventStorming fehlt.

Owner-Teams fuer Mehrheit der Contexts nicht benannt, Map bleibt anonym.

Reale Beziehungen unbekannt, weil Integrationsdokumentation und Tracking fehlen.

Decider fuer Veraenderungen nicht im Raum, Massnahmen bleiben Empfehlung.

Domain ist zu jung, Contexts sind nicht stabil, Map veraltet sofort.

Architektur soll in 6 Monaten gruendlich abgeloest werden, Investment laeuft ins Leere.

Run Sheet durchgearbeitet?

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

Zum Steckbrief Weitere Methoden