methodatlas
Session Builder

Meine Session planen

Plane einen konkreten Arbeitsblock mit Agenda, Rollen, Vorbereitung und kopierbarem Ergebnisartefakt.

Methoden-Session1-3 hWorkshop oder asyncContext Canvas

Session: Bounded Context Canvas

Der Plan übersetzt die Methode in einen konkreten moderierten Arbeitsblock. Die Eingaben fließen direkt in Session Brief und Arbeitsartefakt.

Automatisch abgeleitet

Methoden-Session mit 3-8. Der Plan nutzt die vorhandene Methodenlogik und das Runsheet.

Runsheet
Beteiligungslogik
Teamrunde, gemeinsames Arbeiten und Alignment

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

Ergebnislogik
Artefakt fertigstellen

Die Session arbeitet direkt auf Context Canvas hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

  1. 1

    Sektion 1: Name und Purpose

    10 min

    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.

    FacilitatorContext Canvas
  2. 2

    Sektion 2: Strategic Classification

    10 min

    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.

    FacilitatorGlossary
  3. 3

    Sektion 3: Domain Roles

    10 min

    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.

    FacilitatorIntegration Notes
  4. 4

    Sektion 4: Inbound und Outbound Communication

    30 min

    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.

    FacilitatorContext Canvas
  5. 5

    Sektion 5: Ubiquitous Language und Business Decisions

    20 min

    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.

    FacilitatorGlossary
  6. 6

    Sektion 6: Assumptions und Risiken

    10 min

    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.

    OwnerIntegration Notes
  7. 7

    Artefakt veröffentlichen

    10 min

    Artefakt auf Vollständigkeit prüfen, Ablageort festlegen, Version oder Status setzen und Review-Empfänger benennen.

    OwnerContext Canvas
Nutzbares Artefakt

Session Brief

Für Einladung, Board, Ticket, PR-Beschreibung oder Workshop-Notiz.

session-brief.md

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. 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. 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. 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. 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. 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. 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.
Nutzbares Artefakt

Arbeitsartefakt

Vorgefüllter Startpunkt auf Basis der passenden Vorlage.

arbeitsartefakt.md

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
Vorlagenbasis

Bounded Context Canvas Arbeitsvorlage

Vorlage ansehenKompakte Arbeitsvorlage für Bounded Context Canvas mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
canvas

bounded-context-canvas-working-template.md

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

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.

Direkt nutzbar, wenn
  • Arbeitsfrage, Owner und Zielartefakt sind sichtbar.
  • Das Ergebnis passt zu Context Canvas.
  • Jeder Canvas im Git mit Versionsnummer im Dateinamen oder Header. Bei größeren Änderungen (Domain-Klassifikation, neue Integrationen) neue Version, alte behalten. Änderungs-Log am Ende mit Datum und Anlass.
  • Offene Fragen sind als Follow-up notiert.
  • Der nächste Review oder Entscheidungspunkt ist terminiert.
SteckbriefRunsheet