Komponenten und Verbindungen eines Systems, nach Schicht oder Vertrauensgrenze gruppiert.
1 Beispiel: Architekturdiagramm
Architektur einer Commerce-Plattform
Clients, Dienste und Datenspeicher eines Onlineshops, nach Schicht gruppiert.
Komponenten sind nach Schicht gruppiert, Pfeile laufen von links nach rechts, und die Füllung jedes Knotens sagt, was er ist: Eingänge, Dienste, Speicher, ein externes Warehouse. Nur das API-Gateway, der Integrationspunkt, trägt den Akzent.
Ein Architekturdiagramm zeigt die Bausteine eines Softwaresystems und wie sie verbunden sind: Clients, Services, Datenbanken, Warteschlangen, externe Dienste. Eine verbreitete Methode ist das C4-Modell von Simon Brown mit den Ebenen Kontext, Container, Komponenten und Code.
Kästen sind Komponenten, Pfeile Kommunikationswege, idealerweise mit Protokoll beschriftet. Gruppierungen zeigen Schichten oder Vertrauensgrenzen, etwa was öffentlich erreichbar ist und was nur intern.
Wann ein Architekturdiagramm sinnvoll ist
In einem Architecture Decision Record, um zu zeigen, welche Komponenten eine Änderung betrifft.
Beim Security-Review, um Vertrauensgrenzen und Datenflüsse über diese Grenzen sichtbar zu machen.
Nicht, wenn es um konkrete Server, Regionen und Ports geht: Das ist ein Verteilungsdiagramm.
So erstellst du ein gutes Architekturdiagramm
Entscheide dich für eine Abstraktionsebene und mische nicht Systemkontext mit einzelnen Klassen.
Beschrifte jeden Pfeil mit Richtung und Protokoll, etwa „REST/HTTPS“ oder „Kafka“.
Füge eine kleine Legende hinzu, wenn Farben oder Linienarten etwas bedeuten.
Beschreib deine Services dem KI-Copiloten in MakeCharts, er gruppiert sie nach Schicht.
