Meine Session planen

# Session Brief: Bounded Context Canvas

## Ziel
Artefakt: Context Canvas

## Arbeitsfrage
Welche fachliche Grenze definiert diesen Context, welche Sprache gilt darin und wie integriert er sich mit Nachbarn?

## Kontext
Vorläufiger Context-Name; Liste bekannter Up- und Downstream-Systeme mit Integrationsart; bestehende Service-Dokumentation; relevante ADRs zu Schnittstellen.

## Setup
- Format: Methoden-Session
- Dauer: 1-3 h
- Modus: Workshop oder async
- Teilnehmende: Ein Context-Owner (Team Lead oder Tech Lead); zwei bis drei Domain-Experten aus dem Fachbereich; ein bis drei Engineers; optional ein DDD-Coach für die ersten Canvases im Team.
- Owner: Ein Context-Owner (Team Lead oder Tech Lead)
- 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 Canvas hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

## Input
Bounded-Context-Canvas-Template (ddd-crew GitHub) als Miro-Vorlage oder A1-Druck; Stickies in vier Farben für Domain Roles, Strategic Classification, Inbound, Outbound; Marker; Glossar-Bereich am Rand.

## Vorbereitung
Canvas auf Arbeitsfläche legen, Felder beschriften (Name, Purpose, Strategic Classification, Domain Roles, Inbound Communication, Outbound Communication, Ubiquitous Language, Business Decisions, Assumptions). Glossar-Spalte rechts. Timer auf 90 min.

## Agenda
1. Sektion 1: Name und Purpose (10 min)
   Owner: Facilitator
   Aktion: Context-Name als fachlicher Begriff, nicht als Service-Name. Purpose in zwei Sätzen: welches Geschäftsproblem dieser Context löst und welches Outcome er erzeugt. Hinweis: Wenn der Name wie ein Microservice klingt („order-service“), ist er zu technisch. Fachlicher Begriff aus der Ubiquitous Language nutzen. 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 Canvas

2. Sektion 2: Strategic Classification (10 min)
   Owner: Facilitator
   Aktion: Drei Achsen einordnen: Domain (Core, Supporting, Generic), Business Model (Revenue, Engagement, Compliance, Cost Reduction), Evolution (Genesis, Custom, Product, Commodity). Hinweis: Core-Domains brauchen die besten Leute. Wenn alles als Core klassifiziert wird, ist die Strategie unklar oder das Team überschätzt sich. 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: Glossary

3. Sektion 3: Domain Roles (10 min)
   Owner: Facilitator
   Aktion: Welche Rolle spielt der Context (Specification, Execution, Audit, Approver, Analysis, Gateway)? Mehrere Rollen möglich, aber begründet. Hinweis: Mehr als drei Domain Roles deuten auf einen God-Context hin. Aufteilung in mehrere Canvases prüfen. 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 Notes

4. Sektion 4: Inbound und Outbound Communication (30 min)
   Owner: Facilitator
   Aktion: Pro Schnittstelle: Counterpart-Context, Frequenz, Daten, Integrationsmuster (Customer-Supplier, Conformist, ACL, Open Host Service, Published Language). Inbound Commands und Queries getrennt von Outbound Events. Hinweis: Wenn die Sprache zwischen Inbound und Outbound differiert, ist Übersetzung (ACL) zwingend. Fehlende ACL bei abweichender Sprache erzeugt Modell-Leck. 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 Canvas

5. Sektion 5: Ubiquitous Language und Business Decisions (20 min)
   Owner: Facilitator
   Aktion: 10-20 zentrale Begriffe sammeln, mit kurzer Definition. Drei bis fünf wichtige Business Decisions notieren (Regeln, Policies, Invariants), die der Context durchsetzt. Hinweis: Wenn ein Begriff in unterschiedlichen Stakeholder-Köpfen unterschiedlich besetzt ist, gehört er hier explizit definiert. Sonst leakt die Mehrdeutigkeit in Code und Tickets. 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: Glossary

6. Sektion 6: Assumptions und Risiken (10 min)
   Owner: Owner
   Aktion: Offene Annahmen, fehlende Klarheit und bekannte Risiken festhalten. Pro Eintrag Owner und nächste Aktion benennen. Hinweis: Leerer Assumptions-Block ist ein Warnzeichen. Jeder Context hat unsichere Annahmen, fehlt diese Reflexion, ist der Canvas geschönt. 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 Notes

7. 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 Canvas

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

# Context Canvas: Bounded Context Canvas

## Arbeitsfrage
Welche fachliche Grenze definiert diesen Context, welche Sprache gilt darin und wie integriert er sich mit Nachbarn?

## Kontext
Vorläufiger Context-Name; Liste bekannter Up- und Downstream-Systeme mit Integrationsart; bestehende Service-Dokumentation; relevante ADRs zu Schnittstellen.

## Beteiligte
- Owner: Ein Context-Owner (Team Lead oder Tech Lead)
- Teilnehmende: Ein Context-Owner (Team Lead oder Tech Lead); zwei bis drei Domain-Experten aus dem Fachbereich; ein bis drei Engineers; optional ein DDD-Coach für die ersten Canvases im Team.

## Input
Bounded-Context-Canvas-Template (ddd-crew GitHub) als Miro-Vorlage oder A1-Druck; Stickies in vier Farben für Domain Roles, Strategic Classification, Inbound, Outbound; Marker; Glossar-Bereich am Rand.

## Vorlage
# Bounded Context Canvas 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 Canvas:
- Glossary:
- Integration Notes:

## Offene Fragen

- ...

## Nächster Schritt

Owner, Datum, Erfolgssignal.

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