methodatlas
Session Builder

Meine Session planen

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

Methoden-Session1-3 hWorkshopDomain Context Map

Session: Domain 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 3-10. 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 Domain Context Map hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

  1. 1

    Phase 1: Contexts identifizieren

    30-45 min

    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.

    FacilitatorDomain Context Map
  2. 2

    Phase 2: Beziehungen einzeichnen

    30-60 min

    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.

    FacilitatorBoundary Notes
  3. 3

    Phase 3: Hot Spots markieren

    20-30 min

    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.

    FacilitatorOwnership Map
  4. 4

    Phase 4: Implikationen und Aktionen

    20-30 min

    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.

    OwnerDomain Context Map
  5. 5

    Artefakt veröffentlichen

    10 min

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

    OwnerDomain Context Map
Nutzbares Artefakt

Session Brief

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

session-brief.md

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

Arbeitsartefakt

Vorgefüllter Startpunkt auf Basis der passenden Vorlage.

arbeitsartefakt.md

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
Vorlagenbasis

Domain Context Map Arbeitsvorlage

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

domain-context-map-working-template.md

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

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.

Direkt nutzbar, wenn
  • Arbeitsfrage, Owner und Zielartefakt sind sichtbar.
  • Das Ergebnis passt zu Domain Context Map.
  • Pro Edition Datum und Version. Vorherige Map behalten. Veränderungen (neue Contexts, geänderte Beziehungen, gelöste Hot Spots) als Delta markieren. Mindestens halbjährliche Reviews.
  • Offene Fragen sind als Follow-up notiert.
  • Der nächste Review oder Entscheidungspunkt ist terminiert.
SteckbriefRunsheet