Diagramme, Entscheidungen und Interviews

Ein guter Entwurf, den niemand versteht, ist kaum mehr wert als ein schlechter. Architektur lebt davon, dass sie kommuniziert wird: im Team, gegenüber Kunden, im Vorstellungsgespräch und nicht zuletzt gegenüber dem eigenen zukünftigen Ich, das in zwei Jahren wissen will, warum etwas so gebaut wurde. Diese Lektion zeigt drei bewährte Werkzeuge dafür – Diagramme nach dem C4-Modell, Architekturentscheidungen als kurze Dokumente und ein festes Vorgehen für Entwurfsgespräche – und schließt mit einem Glossar der wichtigsten Begriffe des Kurses.

1. Diagramme mit dem C4-Modell

Viele Architekturdiagramme scheitern daran, dass sie alles auf einmal zeigen wollen: Nutzer, Server, Datenbanktabellen, Klassen und Netzwerkdetails in einem einzigen Bild. Das C4-Modell von Simon Brown löst das mit vier Zoomstufen, ähnlich wie eine Landkarte vom Kontinent bis zur Straße.

Abb. 6.1Die vier Ebenen des C4-Modells

Einige Regeln machen Diagramme deutlich besser: Jedes Diagramm hat einen Titel und eine Legende. Jeder Kasten nennt seinen Zweck, nicht nur einen Namen – „API: Buchungen und Zahlungen, Node.js“ statt nur „Backend“. Jeder Pfeil ist beschriftet und zeigt, was fließt und wie: „liest Kurse, JSON über HTTPS“. Und Diagramme liegen als Text neben dem Code, etwa mit Werkzeugen wie Structurizr oder Mermaid, damit sie mit dem System gepflegt werden und nicht in einer vergessenen Präsentation veralten.

2. Entscheidungen festhalten

Diagramme zeigen, wie ein System aufgebaut ist, aber nicht, warum. Genau diese Frage stellt sich später am häufigsten: Warum wurde die Datenbank nicht aufgeteilt? Warum gibt es hier eine Warteschlange? ADRs beantworten sie in einer halben Seite. Stellen Sie selbst eines zusammen:

Bewährt hat sich, ADRs nummeriert im Code-Repository abzulegen, etwa als docs/adr/0007-buchungen-per-warteschlange.md. Sie sind kurz, meist unter einer Seite, und werden nicht nachträglich geändert. Ändert sich eine Entscheidung, entsteht ein neues ADR, das auf das alte verweist. So entsteht über die Zeit eine Geschichte der Architektur, die neuen Teammitgliedern mehr erklärt als jedes Diagramm.

3. Das Entwurfsgespräch

Ob im Vorstellungsgespräch oder im ersten Workshop mit einem Kunden: Entwurfsgespräche folgen einer erkennbaren Dramaturgie. Klicken Sie sich durch ein typisches Gespräch von 45 Minuten:

4. Eine Checkliste für eigene Entwürfe

Zum Abschluss des Kurses eine Checkliste, die Sie für jeden eigenen Entwurf nutzen können. Sind die funktionalen und nicht funktionalen Anforderungen schriftlich festgehalten, inklusive dessen, was bewusst fehlt? Gibt es eine Überschlagsrechnung für Last, Speicher und Kosten? Ist die Quelle der Wahrheit für jede Datenart klar? Sind Engpässe, einzelne Ausfallpunkte und Fehlerfälle benannt? Gibt es Zeitlimits, Wiederholungen mit Idempotenz und Rate Limits an allen Außengrenzen? Sind Authentifizierung, Autorisierung je Objekt und Mandantentrennung geregelt? Werden die goldenen Signale gemessen und sinnvoll alarmiert? Gibt es Backups mit geprobter Wiederherstellung? Sind die KI-Bausteine mit Evals, Budgets und Leitplanken versehen? Und sind die wichtigsten Entscheidungen als ADR festgehalten? Wer diese Fragen beantworten kann, hat einen Entwurf, der nicht nur funktioniert, sondern sich auch erklären, betreiben und weiterentwickeln lässt.

6. Architektur für Nicht-Techniker erklären

Viele Entscheidungen über Systeme treffen Menschen ohne technischen Hintergrund: die Geschäftsführung, die Budget freigibt, oder der Inhaber eines Cafés, der wissen will, warum sein Onlineshop eine zweite Datenbank braucht. Für sie gelten eigene Regeln. Sprechen Sie über Wirkungen, nicht über Werkzeuge: nicht „wir führen ein Lesereplikat ein“, sondern „die Seite bleibt auch beim Ansturm nach dem Newsletter schnell“. Übersetzen Sie Risiken in Geschäftssprache: Was kostet eine Stunde Ausfall, wie viele Bestellungen gehen verloren, welche Pflicht gegenüber Kunden steht im Raum? Zeigen Sie das Kontextdiagramm statt des Containerdiagramms. Und nennen Sie Optionen mit Preis: „Variante A kostet 20 Euro im Monat und übersteht den Ausfall eines Rechenzentrums, Variante B kostet 200 Euro und übersteht den Ausfall einer ganzen Region.“ So wird aus einer technischen Frage eine Entscheidung, die das Gegenüber selbst treffen kann – und genau das schafft Vertrauen in die Architektur und in die Menschen, die sie verantworten.

Hilfreich ist auch eine gemeinsame Sprache im Team. Wenn alle unter „Verfügbarkeit“, „Mandant“ oder „bestätigte Buchung“ dasselbe verstehen, entstehen weniger Missverständnisse zwischen Fachabteilung, Entwicklung und Betrieb. Das folgende Glossar sammelt die wichtigsten Begriffe dieses Kurses als Ausgangspunkt für ein solches gemeinsames Vokabular.

7. Glossar

Die wichtigsten Begriffe des Kurses auf einen Blick – durchsuchbar:

Mit dieser Lektion haben Sie alle Inhalte des Kurses System Design durchgearbeitet – von den Grundlagen über Daten, Skalierung, Zuverlässigkeit, Schnittstellen und Sicherheit bis zu KI-Systemen, modernen Mustern und vollständigen Fallstudien. Im Abschlusstest können Sie Ihr Wissen noch einmal prüfen.

Stand: September 2026. Kursmaterial der Klarwerk Akademie. Zahlen zu Latenzen und Kosten sind Größenordnungen zur Orientierung, keine Messwerte.