Meine Session planen

# Session Brief: Context Map

## Ziel
Artefakt: Context Map

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

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

## Setup
- Format: Methoden-Session
- Dauer: 3-4 h fuer mittlere Domains, 1 Tag fuer komplexe
- Modus: Workshop oder async
- Teilnehmende: Ein DDD-erfahrener Facilitator; Architekt(en) mit Systemueberblick; Tech Lead pro Context; Product Owner pro Context; ein Scribe.
- Owner: Ein DDD-erfahrener 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 Context Map hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

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

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

## Agenda
1. Phase 1: Contexts inventarisieren (30 min)
   Owner: Facilitator
   Aktion: Alle bekannten Bounded Contexts als Kreise auf der Wand. Pro Context Owner-Team und Kurz-Verantwortung. Doppelung oder Ueberlappung explizit kennzeichnen. Hinweis: Wenn 25 Contexts entstehen, ist die Granularitaet zu fein. Auf strategische Ebene fokussieren, technische Module nicht als eigene Contexts auffuehren. 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: Context Map

2. Phase 2: Beziehungen identifizieren (60 min)
   Owner: Facilitator
   Aktion: Pro Context-Paar fragen: gibt es eine Beziehung (Daten, Events, API). Wenn ja, Pfeil zeichnen (Upstream-Downstream). Beziehungsstaerke und -art notieren. Hinweis: Wenn alle Contexts mit allen verbunden sind, ist die Modularisierung gescheitert oder die Map zu grob. Beides sichtbar machen und nicht uebermalen. 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: Integration Patterns

3. Phase 3: Muster zuordnen (60 min)
   Owner: Facilitator
   Aktion: 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). Hinweis: Muster sind nicht Wunsch, sondern Diagnose. Wenn aktuelle Realitaet Big Ball of Mud ist, das ehrlich kennzeichnen. Zielmuster separat notieren. 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

4. Phase 4: Pain Points und Zielzustand (45 min)
   Owner: Facilitator
   Aktion: Pain Points an Beziehungen markieren (lange Releases, Bug-Risiken, Doppel-Modelle). Pro Top-3-Pain einen Ziel-Beziehungstyp definieren und Massnahmen. Hinweis: Zielzustand ist nicht 100% sauber, sondern eine pragmatische Verbesserung in 6-12 Monaten. ACL einfuehren ist haeufig erster Schritt. 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: Context Map

5. Phase 5: Strategy und Followups (30 min)
   Owner: Owner
   Aktion: Strategische Konsequenzen ableiten: welche Teams uebernehmen welche Beziehung, welche Refactorings noetig, welche Plattform-Faehigkeiten fehlen. Top-3-Massnahmen mit Owner und Frist. Hinweis: Context Map ohne Folgeaktionen ist Diagramm-Tourismus. Mindestens drei Massnahmen mit Erfolgsindikator und 3-Monats-Frist. 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: Integration Patterns

6. 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: Context Map

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

# Context Map: Context Map

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

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

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

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

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

## Fertigstellungscheck
- 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