Architekturstile und Systemzuschnitt

Architekturstile und Systemzuschnitt

0:00 Willkommen zum zweiten Tag. Wir beginnen mit der Frage, die in Architekturdebatten am meisten Energie verbraucht: Monolith oder Microservices? Ich möchte Ihnen vorweg sagen, worauf wir hinauswollen — nämlich nicht auf eine Antwort, sondern auf ein Entscheidungsraster. Denn beide Antworten sind richtig, unter verschiedenen Bedingungen. Und die Bedingungen sind erstaunlich wenig technisch.

0:23 Sie haben mit der Größe Ihrer Domäne zu tun, mit der Zahl Ihrer Teams und mit der Reife Ihres Betriebs.

Architekturstile und Systemzuschnitt

0:29 Der Weg führt über fünf Kapitel. Zuerst der Monolith — und zwar ernsthaft, nicht als Strohmann. Dann Microservices und die Voraussetzungen, die ihr Nutzen verlangt. Danach ein Überblick über die weiteren Stile, denn zwischen diesen beiden Polen liegt das meiste. Viertens die Entscheidung selbst, an Kriterien entlang. Und am Ende entwerfen Sie für Kartenwerk beide Varianten und wählen begründet eine aus.

Monolithische Architekturen

0:55 Fangen wir beim Monolithen an — und bitte ohne das abschätzige Unterton, der dem Wort anhaftet. Eine einzige Auslieferungseinheit ist kein Versäumnis. Sie ist eine Architekturentscheidung mit klaren Stärken. Halten wir die beiden Begriffe auseinander. Ein Monolith ist eine einzige auslieferbare Komponente mit einer Datenbank, in der alle Teilbereiche stecken. Alle Aufrufe laufen lokal.

1:19 Ein modularer Monolith behält genau das bei und zieht zusätzlich verbindliche Modulgrenzen — mit Regeln darüber, wer wen aufrufen darf. Das ist der entscheidende Zusatz: Sie bekommen die Klarheit der Grenzen, ohne die Kosten der Verteilung zu bezahlen. Für die meisten Systeme, die ich sehe, ist das die passende Antwort. Die linke Spalte enthält Vorteile, die in Microservice-Diskussionen gern vergessen werden. Aufrufe sind lokal, also schnell und zuverlässig.

1:47 Abläufe lassen sich als gewöhnliche Transaktion umsetzen — kein Saga-Muster, keine Kompensation, kein Ausgangspostfach. Nach dem letzten Modul wissen Sie, was das wert ist. Rechts die Kosten. Und dann der wichtigste Satz, in der Fußzeile: All diese Nachteile verschärfen sich mit der Größe und der Zahl der Teams. Bei einem Team und überschaubarer Domäne sind es schlicht keine Nachteile.

2:12 So stirbt ein modularer Monolith, und zwar nie mit einem großen Knall. Jemand greift unter Zeitdruck direkt auf die Tabelle eines anderen Moduls zu. Ein gemeinsames Hilfspaket entsteht und wird zum Sammelbecken. Domänenobjekte wandern über Grenzen und ziehen Abhängigkeiten hinter sich her. Jeder einzelne Schritt ist vertretbar, die Summe ist es nicht. Und der vierte Punkt nennt die Ursache für alle drei: Die Regel steht im Wiki, nicht im Bauprozess.

2:38 Eine Regel, die nur Menschen durchsetzen, hält der ersten stressigen Woche nicht stand. Und hier ist das Gegenmittel, das den modularen Monolithen von einer frommen Absicht zu einer tragfähigen Architektur macht. Die Prüfung läuft im selben Lauf wie die Tests, ein Verstoß bricht den Bau. Das klingt streng und ist notwendig — sonst wird aus jedem Verstoß eine geduldete Ausnahme, und geduldete Ausnahmen summieren sich.

3:03 Der letzte Punkt ist die eigentliche Botschaft: Wer so prüft, kann den Monolithen als Dauerlösung wählen. Ohne diese Prüfung ist er immer nur eine Vorstufe, und zwar eine, die sich selbst zerlegt. Der zweite Punkt ist eine sich selbst erfüllende Prophezeiung: Der modulare Monolith gilt als Übergangslösung, wird deshalb nicht gepflegt und ist nach zwei Jahren tatsächlich nicht mehr tragfähig.

3:25 Der dritte ist der häufigste halbe Schritt: Der Code ist getrennt, die Datenbank nicht — und über die Datenbank bleibt alles gekoppelt. Und der letzte Punkt ist der teuerste: Die Zerlegung beginnt, bevor die Grenzen stabil sind. Dann schneidet man an der falschen Stelle und hat die Schnittstelle in Beton gegossen.

Microservice Architecture

3:43 Damit zum anderen Pol. Microservices lösen echte Probleme — und stellen Bedingungen, über die man selten spricht, weil sie nicht technisch sind. Vier Eigenschaften stecken in dieser Definition, und jede ist eine Zumutung. Eine fachliche Fähigkeit innerhalb eines Bounded Context — das setzt voraus, dass Sie Ihre Domäne verstanden haben.

4:04 Ein eigener Datenbestand — kein Zugriff auf fremde Tabellen, nie. Unabhängige Entwicklung, unabhängige Auslieferung, unabhängige Skalierung. Wenn eine dieser Eigenschaften nicht gegeben ist, haben Sie keine Microservice-Architektur. Sie haben verteilte Komponenten, was etwas völlig anderes ist. Erinnern Sie sich an den Satz aus dem vorigen Modul: Ein Architekturstil ist eine Menge von Einschränkungen. Hier stehen sie.

4:31 Eine Verantwortung je Dienst, Unabhängigkeit, keine geteilten Daten. Und dann der vierte Punkt, den ich für den wichtigsten dieses Kapitels halte: Wer eine dieser Regeln bricht, bekommt die Vorteile nicht — die Kosten aber sehr wohl. Das ist keine Drohung, sondern Mechanik. Die Vorteile entstehen aus den Einschränkungen und nicht aus der Zahl der Dienste.

4:52 Schauen Sie sich diese vier Ebenen an und zählen Sie, wie viele davon technisch sind. Der fachliche Schnitt ist eine Verstehensleistung. Der Teamzuschnitt ist eine Organisationsentscheidung. Die Lieferkette ist Handwerk und Investition. Und die Betriebsreife ist Erfahrung, die man nicht kaufen kann. Wenn eine dieser Ebenen fehlt, tragen die drei anderen nicht. Das ist der Grund, warum Microservices in großen Organisationen funktionieren und in kleinen so oft scheitern.

5:21 Das hier ist kein exotischer Sonderfall, sondern das häufigste Ergebnis einer missglückten Zerlegung. Die Symptome sind leicht zu prüfen: Werden die Dienste gemeinsam ausgeliefert? Berührt eine typische Änderung mehrere davon? Teilen sie sich eine Datenbank? Wenn Sie zweimal ja sagen, haben Sie einen verteilten Monolithen.

5:40 Und der letzte Punkt beschreibt, warum das die schlechteste aller Optionen ist: Sie zahlen die volle Rechnung für die Verteilung und behalten die Kopplung. Der erste Punkt ist der Klassiker: geschnitten wird nach technischen Schichten — ein Dienst für die Oberfläche, einer für die Geschäftslogik, einer für die Daten. Das ist ein verteilter Schichtmonolith.

6:01 Der zweite betrifft Conways Gesetz: Drei Teams und zwölf Dienste bedeuten, dass jedes Team vier Dienste gemeinsam ausliefert — die Unabhängigkeit existiert nur auf dem Papier. Und der letzte Punkt ist der, der in Wirtschaftlichkeitsrechnungen fehlt: Betrieb und Abstimmung kosten Geld, jeden Monat.

Weitere Architekturstile

6:18 Verlassen wir die Zweiteilung. Zwischen Monolith und Microservices liegt ein breites Feld — und für viele Systeme liegt die passende Antwort genau dort. Diese Definition ist die theoretische Grundlage für alles in diesem Modul. Ein Stil ist eine Familie von Architekturen mit gemeinsamen Eigenschaften, und er schränkt ein, welche Elemente auftreten und wie sie zusammenhängen dürfen.

6:41 Der letzte Satz ist der entscheidende: Die gewünschten Eigenschaften ergeben sich aus der Einhaltung der Einschränkungen — nicht aus dem Namen. Man kann ein System nicht dadurch skalierbar machen, dass man es Microservice-Architektur nennt. Die rechte Spalte ist die interessante, denn sie ordnet jedem Stil eine Art von Domäne zu. N-Tier: klassische Fachlichkeit, seltene Änderungen.

7:04 Microservices: komplizierte Domäne, häufige Änderungen. Und schauen Sie auf Web-Queue-Worker — eine einfache Domäne mit einzelnen schweren Aufgaben. Für Kartenwerk ist das bemerkenswert passend: Der Vorverkauf ist eine schwere Aufgabe, der Rest nicht. Die Fußzeile ist wichtig: Die Stile schließen sich nicht aus, große Systeme mischen sie je Teilbereich.

7:27 Diese vier Punkte gelten unabhängig vom gewählten Stil, und sie sind der realistische Gegenpol zu jeder Architekturbegeisterung. Die Komplexität muss zur Domäne passen — zu wenig davon führt zum großen Klumpen, zu viel zu einem System, das niemand mehr überblickt. Asynchrone Nachrichten entkoppeln und erzeugen verzögerte Konsistenz und Duplikate; das kennen Sie aus Modul sechs und sieben.

7:49 Und der letzte Punkt ist der, der dauerhaft kostet: Betrieb, Überwachung und Auslieferung wachsen mit der Zahl der Teile. Der erste Punkt ist konkret und passiert oft: Serverless wird gewählt, und die Anwendung braucht zwanzig Sekunden zum Starten — dann zahlen Sie entweder für dauerhaft warme Instanzen oder Ihre Nutzer warten.

8:08 Erinnern Sie sich an das Kriterium Startverhalten aus Modul fünf. Und der letzte Punkt ist die Zusammenfassung dieses Kapitels: Den Stil für das ganze System zu wählen, statt je Teilbereich, ist die Vereinfachung, die am meisten kostet.

Architekturentscheidung: Monolith oder Microservices?

8:21 Jetzt zur Entscheidung selbst. Und zwar so, wie wir Entscheidungen in diesem Seminar treffen: an Kriterien entlang, mit benannten Alternativen und mit Konsequenzen. Der Kern steht im ersten Satz: Es geht nicht um Modernität, sondern um eine Abwägung zwischen Änderungsaufwand und Verteilungskosten. Auf der einen Seite steht, was es kostet, in einem großen zusammenhängenden System etwas zu ändern. Auf der anderen, was es kostet, viele kleine Systeme zu betreiben.

8:50 Beide Kosten sind real, beide wachsen — nur in verschiedene Richtungen. Ihre Aufgabe ist es, den Punkt zu finden, an dem sich die Kurven kreuzen. Und der liegt bei jeder Organisation woanders. Gehen Sie diese sechs Zeilen für Ihr eigenes System durch — das dauert zehn Minuten und ist ehrlicher als jede Grundsatzdiskussion.

9:11 Auffällig ist, dass vier von sechs Kriterien organisatorisch sind: Teams, Liefertakt, Verfügbarkeitsanforderungen, Betriebsreife. Für Kartenwerk ist die Skalierungszeile die interessante: Die Last ist extrem ungleich verteilt, weil nur der Vorverkauf explodiert. Das spricht dafür, genau diesen einen Teil herauszulösen — und sonst nichts.

9:32 Das ist der praktische Weg, und er entschärft die Grundsatzfrage. Der modulare Monolith ist der beste Ausgangspunkt für eine spätere Zerlegung, weil die Grenzen schon gezogen sind. Herausgelöst wird zuerst, was eigene Last oder eigene Verfügbarkeit braucht — bei Kartenwerk also der Vorverkauf. Und jeder Schritt muss für sich einen Nutzen haben, sonst bleibt die Migration nach dem zweiten Dienst stecken.

9:55 Das ist kein hypothetisches Risiko, sondern der Normalfall bei Zerlegungen ohne Zwischennutzen. Der zweite Punkt betrifft die ehrliche Rechnung. Die Kosten der Verteilung — mehr Überwachung, mehr Bereitschaft, mehr Abstimmung — tauchen in Entscheidungsvorlagen praktisch nie auf, weil sie in anderen Budgets landen. Und der letzte Punkt beschreibt das häufigste Ende einer Migration: Der Zwischenstand aus Monolith und einigen Diensten bleibt für immer.

10:20 Das ist nicht per se schlecht — aber es sollte eine Entscheidung sein und nicht das Ergebnis von Erschöpfung.

Praxisübung

10:27 Und jetzt Sie. Zwei Varianten für Kartenwerk, gleichwertig ausgearbeitet, eine begründete Wahl — und das Ganze schriftlich. Der Punkt dieser Übung liegt im Wort gleichwertig. Es ist verführerisch, die bevorzugte Variante sorgfältig auszuarbeiten und die andere als Pflichtübung abzuhaken. Damit verlieren Sie den ganzen Nutzen — denn erst der ernsthafte Vergleich zeigt, welche Kriterien tatsächlich entscheiden. Nutzen Sie die Priorisierung aus Modul zwei.

10:55 Und halten Sie das Ergebnis als Architecture Decision Record fest; in Modul zwölf sehen wir uns an, wie so ein Eintrag aussehen sollte. Achten Sie auf den letzten Teil des Erfolgskriteriums: der Anlass, bei dem die Entscheidung erneut zu prüfen ist. Das ist der Teil, der am häufigsten fehlt und der am meisten wert ist. Er verwandelt eine Entscheidung von etwas Endgültigem in etwas Überprüfbares — zum Beispiel: Wir prüfen neu, wenn ein drittes Team dazukommt oder wenn die Vorverkaufslast das Zehnfache erreicht.

11:25 Und der Hinweis lenkt Sie auf die richtige Stelle: Ein einziger Teilbereich trägt die gesamte Lastspitze. Der zweite Punkt ist der handwerklich wichtigste: Der Schnitt folgt den heutigen Tabellen statt der Fachlichkeit. Das passiert fast automatisch, weil die Datenbank sichtbar ist und die Domäne nicht. Der dritte fehlt in fast jeder Übung: Konsequenzen für Betrieb und Bereitschaft.

11:48 Wer zehn Dienste entwirft, hat auch entschieden, dass jemand nachts für zehn Dienste erreichbar ist. Im nächsten Modul geht es genau darum — worauf das alles läuft.