methodatlas
Session Builder

Meine Session planen

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

Methoden-Session1-4 hWorkshop oder asyncContext Diagram

Session: C4 Model

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

  1. 1

    Sektion 1: System Context

    20-30 min

    Das System in der Mitte als Box. Drumherum die Personen (Nutzer, Operatoren) und externen Software Systems mit denen es interagiert. Pro Beziehung Richtung und Zweck beschriften. Hinweis: Maximal 7-10 Elemente. Mehr deutet darauf hin, dass externe Systeme zu fein gemappt werden oder das System nicht abgegrenzt ist.

    FacilitatorContext Diagram
  2. 2

    Sektion 2: Container

    30-60 min

    System aufzoomen. Container sind separate ausführbare Einheiten oder Datenspeicher (Web App, Mobile App, API Service, Database, Message Broker). Pro Container Technologie und Hauptverantwortlichkeit. Hinweis: Container sind keine Klassen oder Module. Wenn etwas im selben Prozess läuft, ist es kein eigener Container. Anti-Pattern: Container für jede Klasse.

    FacilitatorContainer Diagram
  3. 3

    Sektion 3: Component (nur bei Bedarf)

    30-60 min

    Für komplexe Container ein Component-Diagramm: logische Bausteine innerhalb des Containers (Controllers, Services, Repositories) mit Verantwortlichkeiten. Hinweis: Nicht jeder Container braucht ein Component-Diagramm. Nur die mit echter interner Komplexität. Sonst veralten Diagramme schneller als der Code.

    FacilitatorComponent Diagram
  4. 4

    Sektion 4: Code (optional, selten)

    15-30 min

    Bei kritischen Komponenten ein Code-Diagramm (UML-Klassen, Entitäten). Nur wenn Code-Struktur stark von Architekturentscheidungen abhängt. Hinweis: Code-Ebene ist meist generierbar oder ohnehin im Code. Statisch gepflegt veraltert sie sofort. In 95% der Fälle weglassen.

    FacilitatorContext Diagram
  5. 5

    Sektion 5: Legende und Konsistenz-Check

    10 min

    Legende mit Notation, Farben und Bedeutungen pro Ebene. Cross-Check: Container im Context-Diagramm tauchen als Top-Level im Container-Diagramm auf, Components passen in ihren Container. Hinweis: Inkonsistenz zwischen Ebenen ist der häufigste Lesefehler. Wenn Container A im Kontext erscheint, aber im Container-Diagramm fehlt, ist die Doku falsch.

    OwnerContainer Diagram
  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 Diagram
Nutzbares Artefakt

Session Brief

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

session-brief.md

Session Brief: C4 Model

Ziel

Artefakt: Context Diagram

Arbeitsfrage

Auf welcher Abstraktionsebene welcher Leser welche Architektur-Information aus dem Diagramm zieht?

Kontext

Aktuelle Liste der Container und Components; bekannte externe Systeme; Personas der Nutzer (Endnutzer, Operatoren, andere Systeme); Tech-Stack pro Container.

Setup

  • Format: Methoden-Session
  • Dauer: 1-4 h
  • Modus: Workshop oder async
  • Teilnehmende: Ein Architekt oder Tech Lead als Hauptverfasser; ein bis drei Engineers mit Implementierungswissen; optional Domain-Experten für Kontext-Diagramm; Reviewer aus Nachbarsystemen.
  • Owner: Ein Architekt oder Tech Lead als Hauptverfasser
  • 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 Diagram hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

Input

Diagramm-Tool mit C4-Notation (Structurizr, IcePanel, Mermaid mit C4-Plugin, PlantUML mit C4-PlantUML, draw.io); Repo-Verzeichnis docs/architecture/diagrams/; Legende mit Notation (Person, Software System, Container, Component, Relationship).

Vorbereitung

Diagramm-Tool aufsetzen, Notations-Konvention im Team abstimmen (Farben, Shapes, Pfeilrichtung). Source der Diagramme als Text-DSL im Repo, gerendert beim Build. Für jede Ebene eine eigene Datei.

Agenda

  1. Sektion 1: System Context (20-30 min) Owner: Facilitator Aktion: Das System in der Mitte als Box. Drumherum die Personen (Nutzer, Operatoren) und externen Software Systems mit denen es interagiert. Pro Beziehung Richtung und Zweck beschriften. Hinweis: Maximal 7-10 Elemente. Mehr deutet darauf hin, dass externe Systeme zu fein gemappt werden oder das System nicht abgegrenzt ist. Output: Context Diagram

  2. Sektion 2: Container (30-60 min) Owner: Facilitator Aktion: System aufzoomen. Container sind separate ausführbare Einheiten oder Datenspeicher (Web App, Mobile App, API Service, Database, Message Broker). Pro Container Technologie und Hauptverantwortlichkeit. Hinweis: Container sind keine Klassen oder Module. Wenn etwas im selben Prozess läuft, ist es kein eigener Container. Anti-Pattern: Container für jede Klasse. Output: Container Diagram

  3. Sektion 3: Component (nur bei Bedarf) (30-60 min) Owner: Facilitator Aktion: Für komplexe Container ein Component-Diagramm: logische Bausteine innerhalb des Containers (Controllers, Services, Repositories) mit Verantwortlichkeiten. Hinweis: Nicht jeder Container braucht ein Component-Diagramm. Nur die mit echter interner Komplexität. Sonst veralten Diagramme schneller als der Code. Output: Component Diagram

  4. Sektion 4: Code (optional, selten) (15-30 min) Owner: Facilitator Aktion: Bei kritischen Komponenten ein Code-Diagramm (UML-Klassen, Entitäten). Nur wenn Code-Struktur stark von Architekturentscheidungen abhängt. Hinweis: Code-Ebene ist meist generierbar oder ohnehin im Code. Statisch gepflegt veraltert sie sofort. In 95% der Fälle weglassen. Output: Context Diagram

  5. Sektion 5: Legende und Konsistenz-Check (10 min) Owner: Owner Aktion: Legende mit Notation, Farben und Bedeutungen pro Ebene. Cross-Check: Container im Context-Diagramm tauchen als Top-Level im Container-Diagramm auf, Components passen in ihren Container. Hinweis: Inkonsistenz zwischen Ebenen ist der häufigste Lesefehler. Wenn Container A im Kontext erscheint, aber im Container-Diagramm fehlt, ist die Doku falsch. Output: Container Diagram

  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 Diagram

Abschluss

  • Ergebnisartefakt aktualisieren: Context Diagram
  • 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 Diagram: C4 Model

Arbeitsfrage

Auf welcher Abstraktionsebene welcher Leser welche Architektur-Information aus dem Diagramm zieht?

Kontext

Aktuelle Liste der Container und Components; bekannte externe Systeme; Personas der Nutzer (Endnutzer, Operatoren, andere Systeme); Tech-Stack pro Container.

Beteiligte

  • Owner: Ein Architekt oder Tech Lead als Hauptverfasser
  • Teilnehmende: Ein Architekt oder Tech Lead als Hauptverfasser; ein bis drei Engineers mit Implementierungswissen; optional Domain-Experten für Kontext-Diagramm; Reviewer aus Nachbarsystemen.

Input

Diagramm-Tool mit C4-Notation (Structurizr, IcePanel, Mermaid mit C4-Plugin, PlantUML mit C4-PlantUML, draw.io); Repo-Verzeichnis docs/architecture/diagrams/; Legende mit Notation (Person, Software System, Container, Component, Relationship).

Vorlage

C4 Model 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 Diagram:
  • Container Diagram:
  • Component Diagram:

Offene Fragen

  • ...

Nächster Schritt

Owner, Datum, Erfolgssignal.

Fertigstellungscheck

  • Context Diagram 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

C4 Model Arbeitsvorlage

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

c4-model-working-template.md

Kompakte Arbeitsvorlage für C4 Model mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.

C4 Model 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 Diagram:
  • Container Diagram:
  • Component Diagram:

Offene Fragen

  • ...

Nächster Schritt

Owner, Datum, Erfolgssignal.

Direkt nutzbar, wenn
  • Arbeitsfrage, Owner und Zielartefakt sind sichtbar.
  • Das Ergebnis passt zu Context Diagram.
  • Diagrammquellen im Repo neben Code versioniert. Pro Release oder Major Change Snapshot. Diagramme im Pull Request mit verändertem Code reviewen. Rendered Outputs gehören in den Build, nicht ins Repo.
  • Offene Fragen sind als Follow-up notiert.
  • Der nächste Review oder Entscheidungspunkt ist terminiert.
SteckbriefRunsheet