Die üblichen Verdächtigen: PlantUML, Structurizr & das C4-Model

🛠️ PlantUML: Der Klassiker

PlantUML ist wahrscheinlich das bekannteste Tool für Architecture as Code. Es nutzt eine einfache textbasierte Sprache, um Diagramme wie Sequenzdiagramme, Klassendiagramme, Aktivitätsdiagramme oder Komponentenansichten zu erzeugen.

Ein einfaches Beispiel:

@startuml
actor User
User -> (Login)
@enduml

Ein paar Zeilen Text — und schon entsteht ein hübsches Diagramm. Änderungen im Flow? Text ändern, Diagramm neu generieren, fertig.

🏛️ C4-Model & Structurizr: Struktur statt Chaos

PlantUML ist super flexibel — aber bei größeren Systemen wird es schnell unübersichtlich.
Hier hilft das C4-Model, das Simon Brown entwickelt hat. Es teilt Architekturmodelle in vier klare Ebenen:

  1. Context: Was ist das System und welche externen Akteure gibt es?
  2. Container: Aus welchen Deployable Units besteht es?
  3. Component: Wie setzen sich Container aus einzelnen Komponenten zusammen?
  4. Code: (Optional) Detaillierte Implementierung, z. B. Klassendiagramme.

 

Mit Structurizr kannst du dieses Modell ebenfalls als Code pflegen — entweder in einer eigenen DSL oder in Java/Kotlin. Aus dieser einen Quelle erzeugst du verschiedene Ansichten — immer konsistent.

Der Knackpunkt: Konsistenz

Einen Architekturplan zu zeichnen ist einfach. Ihn konsistent zu halten ist die eigentliche Kunst.

Viele Teams starten motiviert mit PlantUML, merken aber schnell:
Wenn jeder sein Diagramm von Hand anpasst, schleichen sich Inkonsistenzen ein:

  • Komponenten heißen plötzlich unterschiedlich.
  • Beziehungen verschwinden.
  • Gleiche Services tauchen in unterschiedlichen Farben oder mit anderen Labels auf.

Die Folge: Verwirrung — und niemand traut der Doku mehr.

Wie hält man Diagramme konsistent?

Hier kommt der wichtigste Praxisteil: Tools und Prozesse helfen, aber ein bisschen Disziplin braucht es trotzdem.

✅ 1. Nutze zentrale Definitionsdateien

PlantUML erlaubt !include. Damit kannst du z. B. alle Elemente in einer Datei definieren:

' elements.iuml
actor User
component Backend
database Database

Jedes Diagramm bindet diese Datei ein:

!include elements.iuml
User -> Backend
Backend --> Database

So stellst du sicher, dass dieselben Elemente immer gleich heißen und aussehen.

✅ 2. Automatisiere so viel wie möglich

  • CI/CD: Baue deine Diagramme automatisch bei jedem Commit. So merkst du sofort, ob jemand vergessen hat, eine Beziehung zu aktualisieren.
  • Visual Diff: Zeig Diagramm-Änderungen im Pull Request an. So fällt auf, wenn plötzlich eine Verbindung fehlt.
  • Linting: Für größere Projekte lohnt sich ein Skript, das prüft, ob alle Knoten aufgelöst werden oder ob es verwaiste Elemente gibt.

✅ 3. Generiere Diagramme aus „echten“ Daten

Die Königsklasse:
Baue so viel wie möglich aus der Codebasis oder aus Architektur-Modellen.
Beispiele:

  • Mit Structurizr DSL pflegst du alle Beziehungen an einer Stelle.
  • Mit Code-Analyse-Tools kannst du Package- oder Klassendiagramme automatisch aus dem Source Code erzeugen.
  • Manche Teams generieren Sequenzdiagramme aus Logs oder Traces.

Je mehr du generierst, desto weniger Fehlerquellen gibt es.

✅ 4. Einfache, klare Konventionen

Gerade bei PlantUML, das sehr frei ist, helfen Regeln enorm:

  • Welche Farben stehen für was? (z. B. externe Systeme immer grau)
  • Wie heißen Akteure, Container, Schnittstellen?
  • Wann wird ein Akteur als actor gezeichnet, wann als component?
  • Lieber mehrere kleine Diagramme als ein riesiges, unübersichtliches.

Leg diese Regeln im README oder in einem Architektur-Guide ab — am besten versioniert im selben Repo.

✅ 5. Pull Requests auch für Architektur

Wenn Architekturmodelle als Code behandelt werden, gilt:
Änderungen laufen über Pull Requests.
So schaut immer jemand drüber, ob die Änderungen logisch sind.
Was bei Quellcode Standard ist, gilt hier genauso.

Tipps für den Start

Wenn du Architecture as Code mit deinem Team einführen willst, fang klein an:

  1. Pick the low-hanging fruit. Nutzt PlantUML für ein paar Sequenz- oder Klassendiagramme.
  2. Experimentiert mit Templates & Styles. Ein zentrales Styling sorgt für Einheitlichkeit.
  3. Stellt Konventionen auf. Klärt, wer welche Diagramme pflegt und wann.
  4. Automatisiert die Generierung. Zum Beispiel als Teil eurer Doku-Builds.
  5. Testet Structurizr oder das C4-Model. Gerade für Microservices ist das extrem hilfreich.

Fazit: Architektur muss leben

„Architecture as Code“ ist keine Magie — aber es hilft, Architektur so zu behandeln, wie sie es verdient: als etwas Lebendiges, das sich mit dem System verändert.

Tools wie PlantUML oder Structurizr ersetzen dabei keine Architekturarbeit. Aber sie machen es einfacher, gute Architektur zu kommunizieren und aktuell zu halten — ohne Visio-Dateien, die niemand mehr versteht.

Also: Nicht mehr zeichnen, sondern schreiben und generieren.
Und ja — auch Architecture as Code braucht Pflege. Aber es lohnt sich.