methodatlas
Session Builder

Meine Session planen

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

Methoden-Session3-4 h fuer mittlere Domains, 1 Tag fuer komplexeWorkshop oder asyncContext Map

Session: Context Map

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 2-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 Map hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

  1. 1

    Phase 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. Hinweis: Wenn 25 Contexts entstehen, ist die Granularitaet zu fein. Auf strategische Ebene fokussieren, technische Module nicht als eigene Contexts auffuehren.

    FacilitatorContext Map
  2. 2

    Phase 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. Hinweis: Wenn alle Contexts mit allen verbunden sind, ist die Modularisierung gescheitert oder die Map zu grob. Beides sichtbar machen und nicht uebermalen.

    FacilitatorIntegration Patterns
  3. 3

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

    FacilitatorBoundary Notes
  4. 4

    Phase 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. Hinweis: Zielzustand ist nicht 100% sauber, sondern eine pragmatische Verbesserung in 6-12 Monaten. ACL einfuehren ist haeufig erster Schritt.

    FacilitatorContext Map
  5. 5

    Phase 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. Hinweis: Context Map ohne Folgeaktionen ist Diagramm-Tourismus. Mindestens drei Massnahmen mit Erfolgsindikator und 3-Monats-Frist.

    OwnerIntegration Patterns
  6. 6

    Artefakt veröffentlichen

    10 min

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

    OwnerContext Map
Nutzbares Artefakt

Session Brief

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

session-brief.md

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

Arbeitsartefakt

Vorgefüllter Startpunkt auf Basis der passenden Vorlage.

arbeitsartefakt.md

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
Vorlagenbasis

Context Map Arbeitsvorlage

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

context-map-working-template.md

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.

Direkt nutzbar, wenn
  • Arbeitsfrage, Owner und Zielartefakt sind sichtbar.
  • Das Ergebnis passt zu Context Map.
  • Pro Iteration eine Version mit Datum. Vorgaengerversion archivieren, Aenderungen am Beziehungstyp mit Begruendung dokumentieren. Verknuepfung zu ADRs pflicht.
  • Offene Fragen sind als Follow-up notiert.
  • Der nächste Review oder Entscheidungspunkt ist terminiert.
SteckbriefRunsheet