Ingenieurwesen 26 Juni 2026  ·  2 min read

Architecture as Code: Warum Ihre Diagramme in Git leben sollten

Editor
X in ↗
Architecture as Code: Warum Ihre Diagramme in Git leben sollten
Architecture as Code: Warum Ihre Diagramme in Git leben sollten 26 Juni 2026
TL;DR — Architecture as Code bedeutet, dass Ihre Service-Topologie als strukturierte Datei im Repository definiert ist, versioniert wird und Visualisierungen automatisch generiert. Dasselbe Prinzip wie Infrastructure as Code — angewendet auf Dokumentation: die Quelle der Wahrheit ist eine Datei, kein handgezeichnetes Diagramm.

Infrastructure as Code hat verändert, wie Teams Infrastruktur verwalten. Die Kernerkenntnis: Der gewünschte Zustand Ihres Systems sollte eine Datei in der Versionskontrolle sein, keine manuelle Schritt-für-Schritt-Anleitung. Terraform, Pulumi und CloudFormation sind der Tooling-Ausdruck dieser Erkenntnis.

Dieselbe Erkenntnis gilt für Architekturdokumentation — und die meisten Teams haben sie noch nicht angewendet. Ihre Architekturdiagramme leben in Confluence, Miro oder Lucidchart — außerhalb des Repositorys, außerhalb der Versionskontrolle und außerhalb des PR-Review-Prozesses. Sie driften ab. Sie werden falsch. Sie bleiben falsch. Das ist genau der Grund, warum Architekturdiagramme veralten — nicht unachtsame Entwickler, sondern eine strukturelle Trennung zwischen Code und Dokumentation.

Was Architecture as Code wirklich bedeutet

Eine minimale YAML-Service-Definition sieht so aus:

services:
  - name: payments-service
    team: platform
    stack: [Go, PostgreSQL]
    status: active
    depends_on:
      - fraud-detection
      - notification-service

Warum Git der richtige Ort für Architekturdokumentation ist

  • Versionshistorie — Sie sehen, wie die Architektur vor 6 Monaten aussah.
  • PR-Review-Prozess — Architekturänderungen erfordern einen PR. Das Team überprüft sie.
  • CI-Validierung — Das YAML-Schema linten, auf zirkuläre Abhängigkeiten prüfen, validieren, dass jeder Service einen Eigentümer hat.
  • Kolokation mit Code — Die Service-Definition lebt im Repository des Services.

Das Deployment-Muster: Statische Visualisierung aus YAML

Die Visualisierungsschicht liest Ihr YAML und generiert eine statische HTML/JS-Anwendung — einen interaktiven Abhängigkeitsgraphen, der auf jedem Static-Hosting-Anbieter deployed werden kann. Kein Backend, keine Datenbank. Bei jedem Deploy spiegelt der Graph den aktuellen Stand des YAML wider. Für die vollständige Mechanik des Kartierens von Service-Abhängigkeiten — Runtime-Discovery vs. explizite Deklaration, Aufbau der ersten Map und das Hover-Trace-Muster — deckt dieser Leitfaden das vollständige Bild ab.

Service Map ist auf diesem Muster aufgebaut: 1 YAML-Datei → 1 Live-Graph. Deployen Sie auf Ihrer eigenen Infrastruktur, erhalten Sie einen immer aktuellen interaktiven Abhängigkeitsgraphen.

Verwandte Artikel: Warum Architekturdiagramme veralten · Service-Abhängigkeiten kartieren

Mikroservices