3. Einführung in Teil 3: Systeme
Architektur ist die Menge von Entscheidungen, die teuer umzukehren sind. Wie teilen Sie ein System in Teile? Wie sprechen diese Teile miteinander? Wie werden die Daten modelliert? Und wie verhält sich das Ganze unter Last und unter Scheitern? Teil 3 handelt davon, diese Entscheidungen absichtlich zu treffen. Bei einem kleinen Team kann Architektur in ein paar Köpfen leben und sich entwickeln, während Sie vorangehen. In einer großen Organisation (Hunderte Ingenieurinnen, Dutzende Teams, Systeme, die die Karrieren der Menschen, die sie bauen, überleben werden) wird Architektur zu dem, was alle koordiniert hält. Wenn sie klar ist, bewegen sich Teams unabhängig, ohne zu kollidieren. Wenn sie vage ist, wird jede teamübergreifende Abhängigkeit zu einer Verhandlung, und jeder Vorfall zu einem Archäologieprojekt.
Die Einsätze sind am höchsten bei Unternehmen und Behörden. Eine Steuer-Engine, eine Leistungsplattform, eine nationale Gesundheitsakte, oder das Kernkontobuch einer Bank ist langlebig, schwer reguliert, über Abteilungen geteilt, und der Öffentlichkeit rechenschaftspflichtig. Die Entscheidungen, die Sie heute über Kopplung, Datenbesitz, und Qualitätsattribute treffen, werden begrenzen, was für ein Jahrzehnt oder mehr möglich ist. Regulierungsbehörden und Prüferinnen erwarten zunehmend dokumentierte, verteidigbare Architektur, mit echtem Beleg, dass Zuverlässigkeit, Sicherheit, Datenschutz, und Dauerhaftigkeit eingebaut wurden, nicht nachträglich angeschraubt. Die Scheitern, die Schlagzeilen machen, sind architektonische Scheitern: Portale, die am Starttag einknicken, Einreichungssysteme, die zur Frist ablaufen, Migrationen, die Datensätze verlieren oder doppelt zählen.
Dieser Teil beginnt mit den dauerhaften Grundlagen, bewegt sich durch konkrete strukturelle Entscheidungen, dann in die Realitäten von Verteilung, Daten, und Maßstab, und endet mit dem schwierigsten Problem, dem die meisten großen Organisationen tatsächlich gegenüberstehen: die Systeme zu modernisieren, die sie bereits betreiben. Der Faden, der es zusammenhält: gute Architektur ist eine Reihe bewusster Kompromisse, kein modischer Standard.
Kapitel in diesem Teil
3.1 Architekturgrundlagen. Die dauerhaften Werkzeuge, die Technologiemode überleben: Qualitätsattribute (die “-keiten”), architektonisch bedeutsame Anforderungen, Fitnessfunktionen (automatisierte Tests, die eine gewählte architektonische Qualität bewachen) und evolutionäre Architektur, leichtgewichtige Dokumentation mit dem C4-Modell (verschachtelte Architekturdiagramme auf vier Zoomstufen) und arc42 (eine Architekturdokumentationsvorlage), und strukturierte Kompromissanalyse.
3.2 Architekturstile und -muster. Eine Übersicht der wichtigsten Systemformen, vom Monolithen über Microservices, ereignisgesteuerte Architekturen mit CQRS (Command Query Responsibility Segregation, das Lesemodelle von Schreibmodellen trennt) und Event Sourcing (Zustand als anhängenden Ereignisprotokoll speichern), Service Mesh (eine dedizierte Infrastrukturschicht für Dienst-zu-Dienst-Kommunikation) und Gateways, Serverless, und hexagonale und saubere Architektur, mit Leitfaden, wann jede passt, gerahmt vom Conwayschen Gesetz (Systeme neigen dazu, die Kommunikationsstruktur der Organisation zu spiegeln, die sie baut).
3.3 Verteilte Systeme. Die harten Wahrheiten, die in dem Moment erscheinen, in dem Sie eine Netzwerkgrenze überqueren (unzuverlässige Netzwerke, Teilausfälle, keine geteilte Uhr), und die Standardverteidigungen: Konsistenzdenken, Idempotenz (eine Operation sicher wiederholbar machen), Wiederholungen mit Backoff, Schaltkreisunterbrecher (die aufhören, eine scheiternde Abhängigkeit aufzurufen), Sagas (Sequenzen lokaler Transaktionen mit kompensierenden Rückgängig-Schritten), und verteilte Beobachtbarkeit.
3.4 Datenarchitektur und Speicherung. Wie Daten modelliert, gespeichert, konsistent gehalten, und schnell im Maßstab bedient werden: die wichtigsten Speicherparadigmen und wann jedes zu nutzen ist, Polyglotte Persistenz (mehrere spezialisierte Datenspeicher in einem System nutzen), Schemaevolution und Migration, Caching und CDNs (Content-Delivery-Netzwerke), und Transaktionen und Nebenläufigkeit unter Last.
3.5 Skalierbarkeit, Performance, und Resilienz. Drei eigenständige Qualitäten, eingebaut statt nachgerüstet: horizontale und vertikale Skalierung, Zustandslosigkeit und Sharding (Daten über Maschinen nach einem Schlüssel aufteilen), Lastverteilung und Autoscaling, Performance-Budgets, Resilienzmuster und Chaos-Engineering, und Mehrregionen-Katastrophenwiederherstellung, gerahmt von RTO (Wiederherstellungszeitziel) und RPO (Wiederherstellungspunktziel).
3.6 Legacy-Modernisierung. Die inkrementellen Muster, die tatsächlich funktionieren, Würgefeige (ein neues System um das alte herum wachsen lassen, bis das alte pensioniert werden kann) und Zweig-durch-Abstraktion (eine Komponente hinter einer Schnittstelle auf der Hauptentwicklungslinie ersetzen), plus Legacy-Risikobewertung, Großrechner- und COBOL-Betreuung (Common Business-Oriented Language), Datenmigration und Dual-Running, und wie man der Große-Umschreibung-Versuchung widersteht, die die teuersten Scheitern des Feldes produziert.
3.7 Softwarewartung. Die dominante Phase der Softwarelebenszeit: korrektive, adaptive, perfektive, und präventive Wartung, Programmverständnis und Reengineering, und Gestaltung für Wartbarkeit, damit langlebige Systeme erschwinglich änderbar bleiben.
3.8 Interoperabilität und offene Standards. Systeme gestalten, um durch offene Standards statt maßgeschneiderter Integrationen zu interoperieren: technische, syntaktische, und semantische Interoperabilität, Domänenstandards wie FHIR im Gesundheitswesen, und die Kosten proprietärer Lock-in.
3.9 Systems Engineering. Komplexe Systeme End-to-End konstruieren, oft Software, Hardware, Menschen, und Prozesse kombinierend: Lebenszyklus, Anforderungszuweisung und Rückverfolgbarkeit, Schnittstellen, Integration, und Verifikation und Validierung.
3.10 Eingebettete und Echtzeitsysteme. Software für Geräte unter engen Beschränkungen: Echtzeitverhalten und Determinismus, ein RTOS oder Bare-Metal-Firmware, begrenzter Speicher und Strom, Hardware-Interaktion, und sicherheitskritische Standards.
3.11 Cloud-Architektur. Für die Cloud gestalten statt ein Rechenzentrum zu verlagern: Dienstmodelle und Serverless, Regionen und Verfügbarkeitszonen als Scheiterdomänen, das geteilte Verantwortungsmodell, verwaltete-Dienst- und Lock-in-Kompromisse, Multi-Cloud und Hybrid, wenn sie ihre Komplexität verdienen, und kostenbewusste, gut architektierte Gestaltung.
3.12 Ereignisgesteuerte Architektur und Messaging. Systeme bauen, die kommunizieren, indem sie Ereignisse produzieren und auf sie reagieren: Warteschlangen versus dauerhafte Streams, Choreografie versus Orchestrierung, Event Sourcing und CQRS, wo sie sich lohnen, Sagas für verteilte Transaktionen, Zustellgarantien und Idempotenz, und die Muster, die asynchrone Flüsse verlässlich halten.
3.13 Netzwerk und Konnektivität. Das Netzwerk, mit dem eine Anwendungsingenieurin tatsächlich zu tun hat: DNS, TCP und die Entwicklung von HTTP, TLS-Terminierung, Lastverteilung und Reverse-Proxys, Content-Delivery und Edge, Dienstentdeckung und Service Mesh, und die Timeouts, Wiederholungen, und Schaltkreisunterbrecher, die die Unzuverlässigkeit des Netzwerks überlebbar machen.
3.14 Multi-Tenancy und SaaS-Architektur. Viele Kundinnen aus einer Software-Instanz bedienen, ohne sie einander sehen oder aushungern zu lassen: das Isolation-versus-Effizienz-Spektrum, Datenpartitionierung, Pro-Mandant-Quoten gegen laute Nachbarn, Mandantenlebenszyklus, und Kostenzuordnung.
3.15 Caching und Content-Delivery. Ein wenig Veralten gegen große Gewinne in Latenz, Last, und Kosten über die Cache-Hierarchie (Client, Edge und CDN, Reverse-Proxy, Anwendung, und Datenspeicher) eintauschen, während Cache-Invalidierung und Stampede-Schutz als erstklassiges Design behandelt werden.
3.16 API-Gateways und Service Mesh. Nord-Süd-Verkehr an einem API-Gateway handhaben (Routing, Authentifizierung, Ratenbegrenzung, Komposition) und Ost-West-Verkehr durch ein Service Mesh (gegenseitiges TLS, Traffic-Shifting, Wiederholungen, Beobachtbarkeit), und entscheiden, wann ein Mesh seine Komplexität verdient.
3.17 Suche und Informationsretrieval. Suche als erstklassiges System behandeln, vom invertierten Index und Relevanz-Ranking bis zu Anfrageverständnis, Facettierung, und Vektor- und Hybrid-Retrieval, mit echter Relevanzevaluierung statt Rätselraten.
Wie diese Kapitel zusammenhängen
Die Kapitel bauen der Reihe nach aufeinander auf. Kapitel 3.1 gibt Ihnen das Vokabular (Qualitätsattribute und Kompromissanalyse), das jedes spätere Kapitel nutzt; die “-keiten”, die es benennt, sind genau, was die Kapitel 3.4 und 3.5 konkret machen. Kapitel 3.2 verwandelt diese Grundlagen in strukturelle Entscheidungen, und die verteilteren Stile, die es befürwortet (Microservices, ereignisgesteuert, Service Mesh) bringen die Kosten, die Kapitel 3.3 Sie zu verwalten lehrt. Die Kapitel 3.3, 3.4, und 3.5 stützen sich stark aufeinander: Verteilung erzwingt die Konsistenz- und Dauerhaftigkeitsentscheidungen der Datenarchitektur, und zusammen formen Verteilung und Daten, welche Skalierbarkeit und Resilienz Sie tatsächlich erreichen können. Kapitel 3.6 schließt den Kreis, denn die meisten großen Organisationen bauen nicht auf einer leeren Seite: sie entwickeln Systeme der Aufzeichnung, die jede Entscheidung begrenzen, die die früheren Kapitel beschreiben.
Teil 3 reicht auch nach außen. Kapitel 3.2 stützt sich auf die Designprinzipien und das Domain-Driven Design aus Kapitel 2.2, um gute Dienstgrenzen zu finden. Die operativen Disziplinen, die diese Systeme am Laufen halten, leben in Teil 9: Site Reliability Engineering (Kapitel 9.1) und Beobachtbarkeit (Kapitel 9.2) sind, wo architektonische Resilienz in Produktion bewiesen wird. Die Sicherheits- und Datenschutzeigenschaften, die Regulierungsbehörden verlangen, werden hier gestaltet, aber in Teil 4 detailliert, und die Plattform- und Lieferpraktiken in Teil 8 entscheiden, ob eine Architektur tatsächlich von vielen Teams gleichzeitig ausgeliefert und betrieben werden kann.