Skip to content

cherware.de

From IT. Not from theory.

Menu
  • Start
  • Projects
  • Downloads
  • About
  • Contact
Menu

C4-Diagramme mit PlantUML

Posted on 4. July 202524. December 2025 by Christoph Hermanns

Software-Architekturen sind komplex. Ohne die richtige Visualisierung kann es schwierig sein, den Überblick zu behalten, insbesondere wenn Teams wachsen oder Projekte über Jahre laufen. Hier kommen C4-Modelle ins Spiel – eine einfache, aber leistungsstarke Methode, um Software-Architekturen auf verschiedenen Abstraktionsebenen zu dokumentieren. Und mit PlantUML gibt es ein fantastisches Werkzeug, um diese Diagramme effizient zu erstellen und zu pflegen [1, 2].

Was sind C4-Diagramme?

Das C4-Modell (Context, Container, Component, Code) von Simon Brown [3] bietet eine hierarchische Sicht auf Software-Architekturen. Es hilft dabei, Systeme schrittweise zu “entfalten”, von einer hohen Geschäftsperspektive bis hin zu den Details des Codes:

  1. Context-Diagramm (Level 1): Zeigt das Softwaresystem im Kontext seiner Benutzer und anderer Systeme.
  2. Container-Diagramm (Level 2): Zerlegt das System in seine Hauptbausteine (Anwendungen, Datenbanken, Dateisysteme).
  3. Component-Diagramm (Level 3): Vertieft einen Container und zeigt die Komponenten innerhalb davon.
  4. Code-Diagramm (Level 4): Beschreibt die Implementierungsdetails einer Komponente (oft durch UML-Klassendiagramme oder IDE-Tools).

Warum PlantUML für C4-Diagramme?

PlantUML ist ein Open-Source-Tool, das die Generierung von Diagrammen aus einfachem Text ermöglicht. Die Kombination mit der C4-PlantUML-Bibliothek bietet mehrere entscheidende Vorteile:

  • Code-basiert: Diagramme werden als Textdateien gespeichert, was Versionskontrolle (Git!), Diffing und Automatisierung ermöglicht.
  • Wartbarkeit: Änderungen an der Architektur können einfach im Text vorgenommen und neu gerendert werden.
  • Konsistenz: Die vordefinierten C4-Elemente sorgen für ein konsistentes Aussehen der Diagramme.
  • Flexibilität: PlantUML kann in vielen Tools und Umgebungen genutzt werden (IDEs, Wikis, CI/CD).

Die wichtigsten C4-PlantUML-Befehle im Überblick

Die C4-PlantUML-Bibliothek stellt spezifische Makros zur Verfügung, die das Zeichnen von C4-Elementen vereinfachen. Hier sind die Befehle, die am häufigsten verwendet werden:

Grundlegende Elemente

Diese Befehle repräsentieren die Bausteine Ihrer Architektur:

  • Person(alias, "Label", "Beschreibung"): Ein menschlicher Nutzer.
    • Beispiel: Person(kunde, "Kunde", "Nutzt unsere Anwendung")
  • Person_Ext(alias, "Label", "Beschreibung"): Eine externe Person.
  • System(alias, "Label", "Beschreibung"): Ein Softwaresystem innerhalb der Organisation.
    • Beispiel: System(onlineshop, "Online-Shop", "Hauptanwendung für Bestellungen")
  • System_Ext(alias, "Label", "Beschreibung"): Ein externes Softwaresystem.
    • Beispiel: System_Ext(zahlungsprovider, "Zahlungsdienstleister", "Externer Anbieter für Zahlungen")
  • Container(alias, "Label", "Technologie", "Beschreibung"): Eine ausführbare Anwendung oder ein Datenspeicher.
    • Beispiel: Container(webapp, "Web-Applikation", "Java Spring Boot", "Stellt die Benutzeroberfläche bereit")
  • Component(alias, "Label", "Technologie", "Beschreibung"): Eine logische Code-Einheit innerhalb eines Containers.
    • Beispiel: Component(bestellservice, "Bestell-Service", "REST API", "Verwaltet Produktbestellungen")
  • Database(alias, "Label", "Technologie", "Beschreibung"): Eine spezielle Form eines Containers für Datenbanken.

Grenzen und Gruppierungen

Diese Befehle helfen dabei, logische Bereiche und Hierarchien zu definieren:

  • Enterprise_Boundary(alias, "Label") { … }: Die Grenze eines Unternehmens.
    • Alles, was hier eingeschlossen ist, gehört zu Ihrer Organisation.
  • System_Boundary(alias, "Label") { … }: Die Grenze eines bestimmten Softwaresystems.
    • Ideal, um alle Container eines Systems zusammenzufassen.
  • Container_Boundary(alias, "Label") { … }: Die Grenze eines einzelnen Containers.
    • Nützlich, um Komponenten innerhalb eines Containers zu gruppieren.
  • Boundary(alias, "Label") { … }: Eine generische Grenze für allgemeine Gruppierungen.

Beziehungen

Elemente sind selten isoliert. Beziehungen zeigen die Interaktionen:

  • Rel(quelle, ziel, "Label", "Technologie"): Die Standardbeziehung.
    • Beispiel: Rel(kunde, onlineshop, “Nutzt”)
  • Rel_U(…), Rel_D(…), Rel_L(…), Rel_R(…): Beziehungs-Makros, die die Richtung des Pfeils explizit vorgeben (Up, Down, Left, Right). Das ist sehr hilfreich, um das Layout zu steuern!
  • Rel_D(quelle, ziel, "Label", "Technologie"): Bidirektionale Beziehung.

Beispiel: Ein einfaches C4 Context-Diagramm

Lassen Sie uns ein kleines Beispiel für ein Context-Diagramm erstellen:

@startuml
!include C4_Context.puml

title Bestellsystem - Context-Diagramm

Person(kunde, "Kunde", "Surft, bestellt Produkte")
System(onlineshop, "Online-Shop", "Ermöglicht Kunden, Produkte zu bestellen")
System_Ext(zahlungsprovider, "Zahlungsdienstleister", "Verarbeitet Online-Zahlungen")
System_Ext(lagerverwaltung, "Lagerverwaltungssystem", "Verwaltet Produktbestände und Versand")

Rel(kunde, onlineshop, "Nutzt")
Rel(onlineshop, zahlungsprovider, "Sendet Zahlungsanfragen an", "HTTPS/API")
Rel(onlineshop, lagerverwaltung, "Fragt Bestände ab und sendet Bestellungen an", "REST/JSON")
Rel(lagerverwaltung, kunde, "Sendet Versandbenachrichtigungen an")

@enduml

Dieses einfache Skript erzeugt ein klares Diagramm, das zeigt, wie der Online-Shop mit seinen externen Akteuren und Systemen interagiert:

Tipps für besseres Layout und mehr Kontrolle

Neben den grundlegenden Befehlen gibt es weitere Kniffe für die Layout-Gestaltung:

  • Beziehungs-Richtungen nutzen: Wenn ein Pfeil explizit nach oben gehen soll, wird Rel_Up() verwendet. Dies beeinflusst die Platzierung der Elemente.
  • Boundary für Gruppierung: Die Grenzen sind nicht nur logisch, sondern auch visuell extrem wichtig. Elemente innerhalb einer Grenze werden zusammengehalten.
  • Unsichtbare Beziehungen: Manchmal sollen Elemente nah beieinander liegen, ohne eine sichtbare Linie. Dafür kann Rel_Neighbor(element1, element2, "", $hidden=true) genutzt werden.
  • Layout_Landscape() oder Layout_Portrait(): BDie generelle Ausrichtung des Diagramms wird bestimmt.

Fazit

C4-Diagramme mit PlantUML sind eine unschlagbare Kombination für die Dokumentation von Software-Architekturen. Sie ermöglichen die Erstellung klarer, konsistenter und wartbarer Diagramme, die von jedem im Team verstanden werden können. Die Einarbeitung in die Befehle wird die Klarheit der Architekturdokumentation erheblich verbessern.


Weblinks

[1] Open-Source-Tool, das einfache Textbeschreibungen verwendet UML-Diagramme zu zeichnen.
[2] PlantUML Web Server
[3] GitHub – plantuml-stdlib/C4-PlantUML: C4-PlantUML combines the benefits of PlantUML and the C4 model for providing a simple way of describing and communicate software architectures

  • Print (Opens in new window) Print
  • Email a link to a friend (Opens in new window) Email
  • Share on LinkedIn (Opens in new window) LinkedIn
  • Share on Bluesky (Opens in new window) Bluesky
  • Share on Mastodon (Opens in new window) Mastodon
Category: Enterprise Architecture, Platforms & Integration

Post navigation

← AI Through the Ages: A Journey Through Artificial Intelligence’s Most Important Milestones
My first experiments with Nano Banana: Google’s new AI image generator →

2 thoughts on “C4-Diagramme mit PlantUML”

  1. BeatAPI says:
    10. August 2026 at 6:40 PM

    Excellent explanation of how the C4 levels prevent architecture diagrams from becoming either too vague or too detailed. The PlantUML examples make the progression concrete. We use a similar hierarchy when documenting a Music Video Generation API: system context for customers, containers for task orchestration, and component views for provider adapters. A follow-up on keeping diagrams synchronized with code would be very useful.

    Reply
    1. Christoph Hermanns says:
      15. August 2026 at 12:26 PM

      Thanks for the great feedback! Using this pattern for your Music Video Generation API is a fantastic real-world example. The separation from the system context for customers down to the component views for the adapters makes perfect sense.

      Regarding keeping diagrams synchronized with the code: I completely agree. That is definitely the next level of challenge if architecture documentation is to remain alive and valuable in the long run.

      Fortunately, when it comes to keeping diagrams close to the codebase, the tooling is really evolving right now – for example, Mermaid diagrams are now excellently supported directly in VS Code (I recently shared a quick thought on this over on Bluesky).

      Before I tackle a follow-up article on automation: Are you already using approaches like render steps in your pipeline to prevent drift, or are you currently looking for pragmatic ways to achieve exactly this?

      Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Latest News

  • Lutions auf DEV Community: erster Artikel veröffentlicht (NEWS-26 / 8. September 2026)
  • OWASP veröffentlicht Agent Control Standard für KI-Agenten (NEWS-25 / 5. September 2026)
  • Mensch und KI im Mittelstand: Praxisnaher Einstieg für KMU (NEWS-22 / 30. August 2026)
  • Lutions Public Portal 0.3.x: WordPress-News werden abonnierbar und besser auffindbar (NEWS-24 / 30. August 2026)
  • Lutions 0.24.7 und WordPress-Plugin 0.2.1: Medien datenschutzfreundlich einbinden (NEWS-10 / 24. August 2026)

More

  • Implementierung eines MCP-Servers29. August 2026
  • MCP-Server: Der offene Standard zwischen KI-Hosts und deinen Systemen16. August 2026
  • Ein lokaler Umzug als Infrastrukturtest mit Codex9. August 2026
  • Das Grilling-Pattern: Anforderungen schärfen, bevor sie Code werden6. August 2026
  • Das LLM-Wiki in Lutions: Erste Gegenproben im Betrieb27. July 2026
  1. Christoph Hermanns on Agentic AI: Wie ich zu meiner idealen Entwicklungsumgebung kam9. September 2026
  2. Christoph Hermanns on C4-Diagramme mit PlantUML15. August 2026
  3. BeatAPI on C4-Diagramme mit PlantUML10. August 2026
  4. Christoph Hermanns on Das LLM-Wiki in Lutions: Erste Gegenproben im Betrieb28. July 2026
  5. Banana Prompts on My first experiments with Nano Banana: Google’s new AI image generator19. December 2025

ABAP AI Analysis Architecture Automation C4-Model Change Cloud Compliance Experiment GDPR GenAI Governance How-To Integration LLM LLMWiki Lutions MCP Notes Operations Overview PlantUML Reflection Risk SAP Security SME Snippet Strategy Toolbox

  • AI, Data & Automation
  • Allgemein
  • Cybersecurity, Risk & Compliance
  • Enterprise Architecture, Platforms & Integration
  • IT Operations, Resilience & Service Excellence
  • Strategy, Portfolio & Business Impact
  • Imprint
  • Disclaimer
  • Privacy policy
© 2026 cherware.de | Powered by Minimalist Blog WordPress Theme