LikeC4 C4-Diagramme

Was macht LikeC4 C4-Diagramme?

Erstellen Sie gültige C4-Diagramme in der LikeC4-DSL aus einer verbalen Beschreibung oder einem Codebase und validieren Sie sie vor der Auslieferung mit der CLI. Die Referenzen sind nach Themenbereichen aufgeteilt – lesen Sie nur das, was die Aufgabe benötigt, bevor Sie diesen Teil schreiben; erraten Sie keine Syntax.

Alles hier ist gegen likec4 1.59.2 verifiziert (siehe references/setup-and-validation.md für die Festlegung und das Upgrade-Verfahren).

Harte Regeln (nur zwei)

1. Vor der Auslieferung validieren. Führen Sie likec4 validate im Projekt aus und liefern Sie nur bei Exit-Code 0 aus. Wenn keine CLI verfügbar ist → führen Sie die dokumentierte Selbstprüfung durch und offenlegen Sie dies. Vorgehen: references/setup-and-validation.md.
2. Nie DSL-Syntax erfinden. Wenn Sie unsicher sind, öffnen Sie die entsprechende Referenz; falls immer noch unsicher, konsultieren Sie https://likec4.dev/dsl/.

Einrichtung (zuerst, einmal pro Sitzung)

LC4="npx -y [email protected]"
v="$(likec4 --version 2>/dev/null | grep -oE '^[0-9]+\.[0-9]+\.[0-9]+' | tail -1)"
[ -n "$v" ] && [ "$(printf '%s\n1.53.0\n' "$v" | sort -V | head -1)" = "1.53.0" ] && LC4=likec4

Eine installierte CLI wird nur ab >= 1.53.0 verwendet – ältere haben keinen Befehl format und 1.52.0 beendet sich mit Exit-Code 0 bei ungültigen Modellen, sodass beide untenstehenden Prüfungen stillschweigend bestanden würden. Keine globale Installation erforderlich – npx -y [email protected] funktioniert in jeder Umgebung mit Node 22+ und Netzwerk (erster Lauf lädt herunter, dann gecached). Für Projekte, die der Benutzer behält, empfehlen Sie npm install --save-dev [email protected]. Details, Mindestversion, Offline-Fallback und Fehlerkatalog: references/setup-and-validation.md.

Aufgabe → was zu lesen ist

Vorliegende Aufgabe	Lesen
Systemkontext / Landschaft („Wer nutzt es, mit wem spricht es“)	references/levels/l1-context.md
Container („Was läuft darin“, Technologieentscheidungen)	references/levels/l2-container.md
Komponenten (innerhalb eines Containers)	references/levels/l3-component.md
Code-Ebene – Klassen/Schnittstellen einer Komponente	references/levels/l4-code.md
Datenfluss / Szenario / Sequenz (Login, Checkout, Pipeline)	references/levels/flows-dynamic.md
Infrastruktur / „Wo läuft es“	references/levels/deployment.md
Übergreifende DSL-Fragen (Spezifikation, Modell, FQN, Erweiterungen, Prädikate)	references/syntax-core.md
Farben, Formen, Symbole, Legende, Layout	references/styling.md
Bei einem Repository / Quellcode	references/code-to-diagram.md
Installieren, Validieren, Formatieren, Fehler, Vorschau/Export/CI	references/setup-and-validation.md

Struktur an die Aufgabe anpassen

• Kleine Anfrage (ein System, schnelles Kontext-/Container-Bild): beginnen Sie mit templates/minimal/ – 3 Dateien (spec.c4, model.c4, views.c4). Erstellen Sie dafür kein Multi-Ordner-Projekt.
• Reales System (2+ Ebenen, mehrere Systeme, Bereitstellung, Abläufe): verwenden Sie das Layout von templates/full/ – kopieren Sie die Dateien und benennen Sie den Inhalt um:

architecture/
├── spec.c4                 # der EINZIGe Spezifikationsblock: alle Arten
├── model/
│   ├── landscape.c4        # Systeme der obersten Ebene + Akteure
│   ├── <system>.c4         # eine Datei pro System, via extend <system> { … }
│   └── externals.c4        # externalSystem-Elemente
├── deployment/prod.c4      # Knoten + instanceOf (Arten bleiben in spec.c4)
└── views/
    ├── context.c4          # Ebene 1 (Ansichtsindex)
    ├── <system>-views.c4   # Ansichten der Ebenen 2/3 mit Drill-Down
    └── dynamic-flows.c4    # dynamische + Bereitstellungsansichten

Erweitern Sie durch Hinzufügen von Dateien (neues System → neue model/<s>.c4), halten Sie Modell von Ansichten getrennt und die Spezifikation in einer Datei. Alle .c4-Dateien im Ordner werden automatisch zu einem Modell zusammengeführt.

Vorlagen verwenden nur integrierte Themenfarben (im Gültigkeitsbereich = primary, extern = gray über die Art externalSystem, Person = indigo) – keine benutzerdefinierten Farben, keine Tags. Dies bewahrt die C4-Konvention und passt sich hellen/dunklen Themen an.

Arbeitsablauf

1. Eingrenzen – identifizieren Sie das System, die Akteure, die Externen; wählen Sie Ebenen aus. Standard: Kontext + Container; Komponente nur für einen nicht-trivialen Container; eine dynamische Ansicht für jedes Schlüsselszenario (empfohlen); Bereitstellung, wenn die Infrastruktur wichtig ist; Ebene 4 nur auf ausdrückliche Anfrage oder bei klarer Begründung (references/levels/l4-code.md – Standard-Ersatz ist ein Quelllink). Repo als Eingabe → references/code-to-diagram.md. Bei wirklich mehrdeutigem Umfang → eine Frage stellen; andernfalls fortfahren und Annahmen nennen.
2. Einrichten – die passende Vorlage kopieren, die obige LC4-Zeile ausführen.
3. Modellieren, dann Ansichten – Modelldateien schreiben, dann Ansichten mit Drill-Down (view of, navigateTo), dabei für jedes erstellte Diagramm die entsprechende Ebenendatei lesen.
4. Validieren, dann formatieren – $LC4 validate <verz>; Fehler der Art Zeile N: beheben (Katalog in setup-and-validation.md), bis Exit-Code 0 erreicht ist. Dann $LC4 format <verz> und erneut validieren, sodass die Dateien dem kanonischen Stil entsprechen, den die eigenen Werkzeuge des Benutzers erzeugen.
5. Ausliefern – zeigen Sie die Dateibaumstruktur, das Validierungsergebnis und erläutern Sie, wie die Diagramme angezeigt werden können ($LC4 start <verz>; Export/CI-Optionen in setup-and-validation.md).

Qualitätskriterien (vor der Auslieferung prüfen)

• likec4 validate Exit-Code 0 (oder offengelegte Selbstprüfung), stderr sauber.
• likec4 format <verz> --check Exit-Code 0 – Dateien sind in kanonischer Form.
• Jedes Element hat eine Beschreibung; jeder Container/jede Komponente eine technology; jede Beziehung eine gerichtete Bezeichnung (was + wie).
• Jede Ansicht hat einen title; ≤ ~20 Elemente pro Ansicht – überfüllte Ansichten aufteilen.
• Ebenen sind verbunden: Kontext → Container → Komponente über view of / navigateTo.