Meine Session planen

# Session Brief: Domain Context Map

## Ziel
Artefakt: Domain Context Map

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

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

## Setup
- Format: Methoden-Session
- Dauer: 1-3 h
- Modus: Workshop
- Teilnehmende: 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.
- Owner: Ein Architect oder Domain Modeler als Facilitator
- Beteiligungsmodus: Teamrunde, gemeinsames Arbeiten und Alignment
- Ergebnislogik: Artefakt fertigstellen

## Beteiligungslogik
Nutze die Session für gemeinsames Verständnis. Beiträge werden sichtbar gesammelt, Annahmen werden abgeglichen und offene Unterschiede bleiben im Artefakt nachvollziehbar.

## Ergebnislogik
Die Session arbeitet direkt auf Domain Context Map hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

## Input
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.

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

## Agenda
1. Phase 1: Contexts identifizieren (30-45 min)
   Owner: Facilitator
   Aktion: Bounded Contexts oder Subdomänen als Boxes an die Wand kleben. Pro Box: Name, Owner-Team, kurzer Zweck. Subdomain-Typ markieren (Core, Supporting, Generic). Hinweis: Wenn 20+ Contexts entstehen, sind sie zu fein geschnitten oder Subdomänen werden mit Microservices verwechselt. Lieber 6-12 fachliche Contexts. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Domain Context Map

2. Phase 2: Beziehungen einzeichnen (30-60 min)
   Owner: Facilitator
   Aktion: Zwischen Context-Paaren Pfeile ziehen, mit Beziehungstyp beschriften (z. B. Customer/Supplier mit Upstream/Downstream, Conformist, ACL, Shared Kernel). Bei Unklarheit Pfeil mit Fragezeichen. Hinweis: Beziehungstyp ist nicht Datenflussrichtung, sondern Machtverhältnis und Übersetzungsbedarf. Wer das verwechselt, baut falsche Schutzschichten. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Boundary Notes

3. Phase 3: Hot Spots markieren (20-30 min)
   Owner: Facilitator
   Aktion: Pink-Notes an Beziehungen mit Reibung: häufige Bugs, unklare Verantwortung, semantische Konflikte. Auch unbenutzte Beziehungen markieren (potenziell tote Integration). Hinweis: Hot Spots sind wertvoller Output. Mindestens 3-5 erwartbar, sonst war die Diskussion zu höflich. Konkrete Vorfälle nennen, nicht abstrakte Befürchtungen. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Ownership Map

4. Phase 4: Implikationen und Aktionen (20-30 min)
   Owner: Owner
   Aktion: Pro Hot Spot Owner und Folgeaktion festlegen (Spike, ADR, Schnittstellen-Review). Mindestens drei Aktionen mit Datum. Map fotografieren und versionieren. Hinweis: Map ohne Aktionen wird Dekoration. Folge-Termin in 4-6 Wochen, um Aktionen und Veränderungen zu reviewen. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Domain Context Map

5. Artefakt veröffentlichen (10 min)
   Owner: Owner
   Aktion: Artefakt auf Vollständigkeit prüfen, Ablageort festlegen, Version oder Status setzen und Review-Empfänger benennen.
   Output: Domain Context Map

## Abschluss
- Ergebnisartefakt aktualisieren: Domain Context Map
- Ablageort, Version und Review-Empfänger festlegen.
- Owner, nächster Schritt und Reviewtermin festlegen.

# Domain Context Map: Domain Context Map

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

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

## Beteiligte
- Owner: Ein Architect oder Domain Modeler als Facilitator
- Teilnehmende: 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.

## Input
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.

## Vorlage
# 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.

## Fertigstellungscheck
- Domain Context Map ist vollständig genug für Review:
- Ablageort:
- Version / Status:
- Review durch:
- Nächster Schritt:

## Nächster Schritt
- Ergebnis prüfen
- offene Fragen markieren
- Review oder Entscheidung terminieren