Der Spickzettel zum Seminar Architektur und Technologien für moderne Web-Anwendungen, erster Teil: die Bausteine einer Anwendung — Treiber und Qualitätsziele, Webplattform, Rendering, Backend-Struktur, Schnittstellen und Daten. Systemzuschnitt, Betrieb, Sicherheit und Dokumentation stehen auf dem zweiten Blatt, Systemzuschnitt und Betrieb.
Das Blatt ersetzt keine Entwurfsarbeit. Es hilft beim Erinnern, wenn die Entscheidung ansteht und der Name des Rasters gerade fehlt.
Ebenen und Entscheidungstypen
Wer über „Architektur” spricht, meint eine von drei Ebenen. Solange sie durcheinandergehen, wird keine davon entschieden.
| Ebene | Gegenstand | Typische Frage |
|---|---|---|
| Softwarearchitektur | Struktur einer Anwendung | Welche Module, welche Abhängigkeiten? |
| Systemarchitektur | Zusammenspiel der Systeme | Welcher Dienst kennt welchen? |
| Infrastruktur | Laufzeit und Betrieb | Worauf läuft das, wie kommt es dorthin? |
Die zweite Sortierung entscheidet, wo Aufwand hingehört: Reversibles schnell entscheiden und notfalls korrigieren, schwer Reversibles mit Alternativen und schriftlichem Beleg.
| Reversibel | Schwer reversibel |
|---|---|
| Wahl einer Bibliothek | Schnitt der Fachdomäne |
| Format einer Antwort | Datenhoheit je Dienst |
| Anordnung im Frontend | Synchron oder ereignisgetrieben |
| Betriebsparameter | Verteilung auf eigene Dienste |
Modul: Moderne Webarchitekturen im Überblick
Architekturtreiber und Qualitätsattribute
Ein Architekturtreiber ist eine Anforderung, die den Bauplan verändert. Prüffrage: Was sähe ohne sie anders aus?
| Anforderung | Strukturwirkung |
|---|---|
| Ein Vorgang lässt sich stornieren | keine — neue Funktion in bestehender Struktur |
| Lastspitze mit tausendfachem Zugriff | ja — Skalierung, Entkopplung, Warteschlangen |
| Zahlungsdaten bleiben im Hause | ja — Schnitt, Datenhoheit, Betriebsmodell |
| Zwei Teams liefern unabhängig | ja — Modulgrenzen oder eigene Dienste |
Jedes Qualitätsattribut hat einen konkreten Hebel im Entwurf. Ohne diesen Hebel ist es ein Adjektiv.
| Attribut | Was es im Entwurf verändert |
|---|---|
| Änderbarkeit | Modulgrenzen, Abhängigkeitsregeln, Testbarkeit |
| Skalierbarkeit | Zustandslosigkeit, Entkopplung, Datenpartitionierung |
| Verfügbarkeit | Redundanz, Rückfallebenen, Wiederherstellungsziele |
| Sicherheit | Vertrauensgrenzen, Identität, Datenhaltung |
| Beobachtbarkeit | Instrumentierung, Korrelation, Telemetriepfade |
| Barrierefreiheit | Auslieferungsform, Semantik, Rendering-Entscheidung |
| Kosten | Betriebsmodell, Skalierungsverhalten, Managed Services |
Als Prüfraster über eine Entscheidung taugen die fünf Säulen des Well-Architected Framework: Zuverlässigkeit, Sicherheit, Kostenoptimierung, operative Exzellenz, Effizienz. Sie sind eine Checkliste, keine Rangfolge — und das Framework nennt zu jeder Säule ausdrücklich Abwägungen.
Modul: Anforderungen und Architekturtreiber
Web Platform Baseline
Baseline beantwortet, ob eine Browserfunktion einsatzreif ist — gemessen an vier Kern-Browsern: Chrome für Desktop und Android, Edge, Firefox für Desktop und Android, Safari für macOS und iOS.
| Stufe | Bedeutung |
|---|---|
| Limited availability | Noch nicht in allen Kern-Browsern unterstützt |
| Newly available | In allen Kern-Browsern verfügbar, damit interoperabel |
| Widely available | 30 Monate nach Newly available — ohne Vorbehalt einsetzbar |
Jahresversionen wie Baseline 2026 bündeln, was im jeweiligen Jahr Newly available geworden ist. Für interne Anwendungen mit gepflegter Browserflotte genügt die mittlere Stufe; für öffentliche Auftritte ist die obere die sichere Wahl.
Modul: Webplattform und Laufzeitarchitektur
HTTP-Versionen und Übertragungskanäle
Die Semantik — Methoden, Statuscodes, Header, Caching — steht in RFC 9110 und gilt für alle Versionen. Verschieden ist nur die Übertragung: RFC 9112 für HTTP/1.1, RFC 9113 für HTTP/2, RFC 9114 für HTTP/3.
| Merkmal | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
| Format | Text | binär | binär |
| Transport | TCP | TCP | QUIC über UDP |
| Multiplexing | mehrere Verbindungen | eine Verbindung | eine Verbindung |
| Header-Kompression | nein | ja | ja |
| Head-of-Line-Blockade | ja | auf TCP-Ebene | nein |
Die Wahl des Kanals ist eine Architekturentscheidung, keine Konfiguration.
| Kanal | Einsatzfeld |
|---|---|
| Request-Response | Regelfall, überall zwischenspeicherbar |
| Server-Sent Events | Server schickt fortlaufend, Client hört zu |
| WebSockets | beide Seiten sprechen, Verbindung bleibt offen |
| WebTransport | mehrere Ströme, auch ungeordnet, über QUIC |
Modul: Webplattform und Laufzeitarchitektur
Rendering-Formen und Frontend-Zuschnitte
Vier Grundformen, danach nur noch Mischungen. Die Maße dahinter sind immer dieselben: Zeit bis zur ersten Antwort, bis zum ersten Inhalt, Reaktion auf Eingaben.
| Form | Stärke | Preis |
|---|---|---|
| Serverseitig | schnelle erste Darstellung, wenig Skript | höhere Antwortzeit des Servers |
| Clientseitig | flexible Datenaktualisierung | späte erste Darstellung, große Bündel |
| Statisch | gleichbleibend schnell, am Rand ablegbar | schwierig bei vielen oder persönlichen Seiten |
| Inkrementell statisch | statisch mit Nachliefern einzelner Seiten | zusätzliche Regeln für Gültigkeit |
Gegen das unheimliche Tal der Hydration — die Seite sieht fertig aus, reagiert aber nicht — helfen Streaming, progressive Hydration und Islands Architecture. Am wirksamsten bleibt weniger Interaktivität.
| Zuschnitt | Trägt, wenn |
|---|---|
| Multi-Page Application | Inhalte im Vordergrund stehen, Interaktion punktuell bleibt |
| Single Page Application | die Anwendung wie ein Arbeitswerkzeug benutzt wird |
| Progressive Web Application | Installation, Offline-Fähigkeit oder Benachrichtigungen zählen |
| Backend for Frontend | mehrere Oberflächen sehr verschiedene Zuschnitte brauchen |
| Microfrontends | mehrere Teams unabhängig ausliefern müssen und dürfen |
Modulare Frontends innerhalb eines Deployments sind der unterschätzte Mittelweg: Grenzen ohne Verteilungskosten.
Modul: Frontend- und Rendering-Architekturen
Schichten, Ports und Plattformwahl
Schichten trennen Zuständigkeiten, Tiers trennen Maschinen — logische Trennung erzwingt keine physische.
| Variante | Regel | Folge |
|---|---|---|
| geschlossen | nur die nächsttiefere Schicht | wenige Abhängigkeiten, viel Durchreichen |
| offen | jede tiefere Schicht | weniger Leerlauf, mehr Kopplung |
Ports and Adapters dreht die Abhängigkeitsrichtung um: Ein Port beschreibt ein zweckgerichtetes Gespräch, ein Adapter übersetzt es in Technik. Treibende Adapter beginnen das Gespräch (Oberfläche, Schnittstelle, Testrahmen), getriebene werden angesprochen (Datenbank, Nachrichtensystem, Fremddienst).
| Kriterium der Plattformwahl | Leitfrage |
|---|---|
| Kompetenz im Haus | Wer betreibt und erweitert das in drei Jahren? |
| Reifegrad und Ökosystem | Gibt es tragfähige Bibliotheken für unsere Fachthemen? |
| Langfristige Wartbarkeit | Wie lange werden Versionen gepflegt, wie verlaufen Umstiege? |
| Betriebsanforderungen | Passt das Laufzeitverhalten zum geplanten Hosting? |
| Startverhalten | Wie reagiert die Plattform auf schnelles Hoch- und Herunterfahren? |
| Einstellungsmarkt | Finden wir Leute — und halten wir sie? |
Keines dieser Kriterien ist technisch entscheidbar; alle sind an der eigenen Organisation zu beantworten.
Modul: Backend- und Anwendungsarchitekturen
REST-Reifegrad und Integrationsstile
| Stufe | Was hinzukommt | Woran man sie erkennt |
|---|---|---|
| 0 | HTTP als Tunnel | ein einziger Endpunkt, alles per POST |
| 1 | Ressourcen | eigene Adressen statt einer Sammelstelle |
| 2 | Verben und Statuscodes | GET liest, POST erzeugt, 409 meldet Konflikt |
| 3 | Hypermedia-Steuerung (HATEOAS) | Antworten tragen Links auf mögliche nächste Schritte |
Die meisten Schnittstellen stehen auf Stufe 2. Bewusst dort zu bleiben ist legitim; unbewusst auf Stufe 1 zu stehen ist das Problem.
| Gehört ins Gateway | Gehört nicht hinein |
|---|---|
| Authentifizierung und Token-Prüfung | Fachliche Entscheidungen |
| Aufrufbegrenzung und Kontingente | Datenzusammenführung mit Fachregeln |
| Weiterleitung und Protokollumsetzung | Zustand eines Vorgangs |
| Einheitliche Protokollierung | Sonderfälle einzelner Aufrufer |
Auf der asynchronen Seite entscheidet die Begriffswahl über den Schnitt. Ein
AsyncAPI-Dokument wird dabei aus Sicht einer Anwendung geschrieben:
action: send heißt, dass diese Anwendung sendet.
| Begriff | Bedeutung |
|---|---|
| Event | etwas ist geschehen, Empfänger unbekannt |
| Command | etwas soll geschehen, Empfänger bekannt |
| Queue | eine Nachricht, ein Verarbeiter |
| Event Stream | eine Nachricht, viele Leser, eigene Leseposition |
Modul: APIs und Integrationsarchitekturen
Speichermodelle und verteilte Daten
Die Auswahl beginnt beim Zugriffsmuster, nicht beim Produkt.
| Bedarf | Modell |
|---|---|
| Strenge Transaktionen über mehrere Entitäten | relational |
| Sich wandelnde Aggregate, JSON-nahe Zugriffe | Dokument |
| Sehr schnelle Zugriffe über einen Schlüssel | Key-Value |
| Breite, dünn besetzte, schreibintensive Telemetrie | Column-Family |
| Tiefe Beziehungspfade | Graph |
| Volltextrelevanz und Filterung | Suchindex |
| Ähnlichkeit über Bedeutung | Vektorsuche |
| Zeitfenster über Messwerte | Zeitreihen |
| Große Binärdaten | Objektspeicher |
Wie weit die Atomarität reicht, ist die stillste Modellentscheidung — sie legt die Transaktionsgrenze fest.
| Modell | Atomarität | Schema |
|---|---|---|
| relational | mehrere Zeilen | beim Schreiben festgelegt |
| Dokument | ein Dokument | beim Lesen gedeutet |
| Column-Family | Zeile oder Familie | Familien fest, Spalten frei |
| Key-Value | ein Schlüssel | undurchsichtiger Wert |
Sobald Daten mehreren Diensten gehören, braucht es Muster für das, was in einer Datenbank die Transaktion erledigt hat.
| Muster | Nutzen | Preis |
|---|---|---|
| Saga | Ablauf über mehrere Dienste, kein 2PC | keine Isolation, Kompensation nötig |
| Transactional Outbox | Schreiben und Melden werden zuverlässig eins | zusätzlicher Prozess, Verzögerung |
| CQRS | eigene Lesemodelle, skalierbar und passgenau | mehr Teile, verzögerte Sichten |
| Event Sourcing | lückenloser Verlauf, Zustand zu jedem Zeitpunkt | schwer abfragbar, erzwingt CQRS |
Das CAP-Theorem greift nur bei einer Netzwerkpartition — dann steht die Wahl zwischen Konsistenz und Verfügbarkeit, nicht dauerhaft.
Modul: Datenarchitekturen und Zustandsmanagement
Typische Fallen
- Qualitätsziele als Adjektive. „Schnell und sicher” kann niemand verletzen und entscheidet deshalb nichts. Auslöser, Umgebung und messbare Antwort nennen.
- Alles ist hoch priorisiert. Eine Priorisierung, die nichts zurückstellt, ist keine.
- Serverseitig gerendert und trotzdem das ganze Bündel geladen. Dann zahlt man die Kosten beider Welten.
- Auf dem Entwicklungsrechner gemessen. Der Unterschied zwischen Rendering-Formen zeigt sich erst auf einem alten Mobilgerät.
- Ordner heißen nach Schichten, Abhängigkeiten halten sich nicht daran. Die Regel gehört in den Bauprozess, nicht ins Wiki.
- Die Beschreibung wird aus dem Code erzeugt und nie gelesen. Contract-first heißt, die Beschreibung steht vor der Implementierung.
- Der Empfänger ist nicht idempotent. „Mindestens einmal” ist der Regelfall — Duplikate sind Normalbetrieb, keine Störung.
- Sitzungszustand liegt im Prozess. Damit ist die Zustandslosigkeit aufgegeben und horizontales Skalieren blockiert.
- Der Partitionsschlüssel wird gewählt, bevor die Abfragen bekannt sind. Später lässt er sich kaum noch ändern.
- Mehrere Dienste teilen sich eine Datenbank. Dann sind es keine mehreren Dienste, sondern ein System mit verteilter Auslieferung.
Dieses Thema als Schulung für Ihr Team
Dieser Beitrag erklärt das Thema. Damit Ihr Team es danach auch anwendet, gibt es Architektur und Technologien für moderne Web-Anwendungen als Schulung — an Ihrem eigenen Code, mit den Fragen, die ein Text nicht beantwortet. Sie wählen die Module, wir bauen daraus ein Programm.
2 Tage·ab 900 EUR netto pro Tag (bis 3 Teilnehmende) ·Termin nach Vereinbarung
Als Team-Schulung anfragenZum Seminar Architektur und Technologien für moderne Web-Anwendungen →