Fünf Bücher, ein System: Architektur von der Entscheidung bis zum zuverlässigen Betrieb

ARCCLOUD / ARCHITEKTURWERKSTATT / 02

Am Donnerstag funktionierte alles. Am Freitag bekamen zwei Personen denselben Termin.

Das Team ergänzte die Lageranbindung, verbesserte das Formular und veröffentlichte eine neue Version. Die Pipeline war grün. Am Morgen nahm ein Kundenberater zwei Aufträge für dasselbe Einsatzteam an. Für einen davon war bereits ein Ersatzteil reserviert, für den anderen war die Bestätigung schon an den Kunden verschickt. Jeder einzelne Codeabschnitt tat etwas Vernünftiges. Der Gesamtprozess passte nicht mehr zusammen.

In solchen Momenten ist Architektur keine Zeichnung aus Rechtecken mehr. Sie wird zur Antwort auf konkrete Fragen: Wer darf einen Termin bestätigen, wer ist für die Reservierung verantwortlich und was haben wir dem Menschen auf der anderen Seite des Bildschirms versprochen?

Ich habe fünf Bücher ausgewählt, die dir helfen, diese Fragen in einer sinnvollen Reihenfolge anzugehen. Wir beginnen bei den Anforderungen, sehen uns den Code an, ordnen das bestehende System und prüfen zum Schluss, ob wir es nach der Bereitstellung auch betreiben können. Jedes Buch bringt eine andere Perspektive ein. Sie verbindet die Verantwortung für die Folgen der eigenen Entscheidungen.

Anforderungen · Entwurfsmuster im Code · Refactoring · Grenzen und Ereignisse · Zuverlässigkeit · Prüfe deine Entscheidungen

01 / FUNDAMENTALS OF SOFTWARE ARCHITECTURE

Ein guter Entwurf beginnt mit einem Problem, das wir benennen können.

Mark Richards und Neal Ford geben einen Überblick über Architekturstile und Qualitätsmerkmale eines Systems. Ihr Ausgangspunkt ist einfach: Eine Architekturentscheidung hat ihren Preis. Wenn wir unabhängiger bereitstellen wollen, müssen wir dafür womöglich eine aufwendigere Fehlersuche in Kauf nehmen. Wenn wir eine Transaktion vereinfachen, binden wir möglicherweise einen Teil der Änderungen an eine gemeinsame Bereitstellung. Es lohnt sich, das Buch als Training für das Begründen von Entscheidungen zu lesen. Beschreibung der zweiten Auflage beim Verlag.

Bei ServiceNord entwickeln drei Personen eine Anwendung. Die meisten gemeldeten Probleme betreffen Termine und Ersatzteilreservierungen. Das ist Grund genug, mit den Prozessregeln zu beginnen. Allein die Aussage, das Unternehmen wolle eine „moderne Architektur“, verrät noch nicht, welche Lösung ihm hilft.

Erst jetzt ergibt das Gespräch über den Architekturstil Sinn. Für dieses Unternehmen wählen wir zunächst einen modularen Monolithen: eine gemeinsame Bereitstellung mit ausdrücklichen Verantwortungsgrenzen. Das vereinfacht den Start und ermöglicht lokale Transaktionen. Wir nehmen dabei auch die Kosten gemeinsamer Releases und die Notwendigkeit in Kauf, die Abhängigkeiten zwischen den Modulen zu kontrollieren.

Diese Wahl gilt für die beschriebenen Bedingungen. Wenn ein eigenes Team die Terminplanung weiterentwickelt oder sich ihre Last deutlich von der übrigen Anwendung unterscheidet, kommen wir auf die Entscheidung zurück. Ein gutes Architekturdokument nennt auch einen Auslöser dafür, es erneut zu lesen.

02 / PATTERNS OF ENTERPRISE APPLICATION ARCHITECTURE

Ein Entwurfsmuster hilft erst, wenn es zur Komplexität der Regeln passt.

Martin Fowler, gemeinsam mit seinen Mitautoren, beschreibt wiederkehrende Probleme von Geschäftsanwendungen: die Strukturierung der Logik, das Speichern von Daten oder die gleichzeitige Änderung von Informationen. Das frühere Erscheinungsdatum mindert den Wert der gestellten Fragen nicht. In der Praxis hilft es, ein einfaches Transaction Script von einem reichhaltigeren Domain Model zu unterscheiden und die Grenzen einer Unit of Work zu verstehen. Buchseite des Autors.

Nehmen wir an, die Verwaltung ändert die Beschreibung eines Reparaturarbeitsplatzes. Berechtigungen prüfen, Länge kontrollieren, speichern: Ein einfacher Fall kann ein einfaches Transaktionsskript bleiben. Wir müssen darum kein umfangreiches Modell bauen.

Eine Reparatur zu bestätigen ist schwieriger. Wir benötigen einen freigegebenen Kostenvoranschlag, Ersatzteile und ein Einsatzteam. Werden diese Bedingungen im Controller, in einem nächtlichen Job und in einer Integration getrennt geprüft, haben wir nach einigen Monaten drei verschiedene Definitionen eines „bestätigten Auftrags“. Es lohnt sich, die Regel in einem Modell zusammenzuführen.

public enum WorkOrderState { Draft, Confirmed }

public sealed record ConfirmationEvidence(
    bool QuoteAccepted,
    bool PartsReserved,
    bool TechnicianReserved);

public sealed class WorkOrder
{
    public WorkOrderState State { get; private set; }

    public void Confirm(ConfirmationEvidence evidence)
    {
        if (State == WorkOrderState.Confirmed) return;
        if (!evidence.QuoteAccepted || !evidence.PartsReserved ||
            !evidence.TechnicianReserved)
            throw new InvalidOperationException("Confirmation is incomplete.");

        State = WorkOrderState.Confirmed;
    }
}

Dieser Ausschnitt zeigt eine einzelne Regel, keinen fertigen Prozess für den Produktivbetrieb. In einer laufenden Anwendung muss der Reservierungsnachweis über einen vertrauenswürdigen Vertrag kommen und sich auf den richtigen Auftrag sowie die richtige Version beziehen. Auch ablaufende Reservierungen, Berechtigungen und gleichzeitige Schreibzugriffe müssen behandelt werden. Drei boolesche Werte aus dem Browser sind kein solcher Nachweis.

Im Unit-Test prüfen wir, ob das Modell unvollständig erfüllte Bedingungen zurückweist. Im Integrationstest führen wir zwei Schreibzugriffe gleichzeitig aus und prüfen die Nebenläufigkeitskontrolle in der Datenbank. Das sind zwei unterschiedliche Arten von Gewissheit. Ein Test der Klasse allein deckt keine Doppelbuchung auf, die zwei Prozesse verursachen.

Unit of Work hilft, die Änderungen eines Speichervorgangs zusammenzufassen. Sie erweitert die Transaktion nicht automatisch auf ein externes Lagersystem, einen Broker und einen Mailserver. Diese Grenze sollten wir einzeichnen, bevor der Code sie unbemerkt überschreitet. Kurze Beschreibungen der Muster: Transaction Script, Domain Model und Unit of Work.

03 / DOMAIN-DRIVEN REFACTORING

Kläre zuerst die Bedeutungen. Trenne dann den Code.

Alessandro Colla und Alberto Acerbis zeigen die Anwendung von DDD auf ein bestehendes System: von der Fachsprache und den Kontexten bis zur Änderung der Struktur und der Datenbank. Entscheidend ist das Vorgehen selbst: Grenzen schrittweise verbessern und das Produkt dabei funktionsfähig halten. Ein modulares System kann ein gutes Ergebnis des Refactorings sein; die Ausgliederung eines Microservices braucht eine eigene Begründung. Das Buch beim Verlag.

In unserem Unternehmen bedeutet das Wort „fertig“ für drei Personen etwas anderes. Der Kundenberater meint einen vereinbarten Preis, der Lagermitarbeiter ein zurückgelegtes Ersatzteil und der Techniker eine abgeschlossene Reparatur. Eine einzige Spalte Status beseitigt diesen Unterschied nicht. Sie versteckt ihn bis zum ersten ungewöhnlichen Fall.

Wir beginnen, Grenzen im Gespräch mit den Menschen festzulegen, die die Arbeit erledigen. Wir fragen nach einer konkreten Reklamation: Was ist passiert, wer hat entschieden und welche Information fehlte damals? Aus solchen Gesprächen entsteht ein brauchbares Modell. Die Ordnernamen sollten dieses Modell erst im nächsten Schritt widerspiegeln.

Wie bringst du ein Altsystem voran, ohne es komplett neu zu schreiben?

1. Wähle einen problematischen Anwendungsfall. Zum Beispiel die Terminbestätigung. Halte die Regel gemeinsam mit der für den Prozess verantwortlichen Person fest.
2. Sichere das benötigte Verhalten mit Tests ab. Kläre, welche aktuellen Ergebnisse korrekt sind. Einen alten Fehler in einem Test festzuschreiben macht ihn noch nicht zur Anforderung.
3. Führe einen einzigen Zugriffsweg ein. Der Code für Aufträge fordert eine Reservierung über den Vertrag der Terminplanung an. Er verändert deren Tabellen nicht direkt.
4. Übertrage die Verantwortung für Schreibzugriffe. Lege den Umschaltzeitpunkt und einen einzigen Verantwortlichen fest. Zwei unabhängige Mechanismen, die dieselben Daten schreiben, erschweren das Erkennen von Abweichungen.
5. Vergleiche die Ergebnisse und entferne den alten Weg. Prüfe historische Daten, Grenzfälle und den Rückfallplan. Räume erst danach unnötige Abhängigkeiten auf.

Eine gemeinsame Datenbank kann in dieser Phase bestehen bleiben. Datenverantwortung bedeutet Verantwortung für Änderungen, Regeln und den Vertrag, nicht automatisch einen eigenen Datenbankserver. In einem modularen Monolithen können wir mit Schemas, der Sichtbarkeit von Typen und Abhängigkeitstests beginnen. Wo wir stärkere Isolation brauchen, ergänzen wir passende Berechtigungen und Ausführungsgrenzen.

04 / SOFTWARE ARCHITECTURE: THE HARD PARTS

Wenn ein Modul zum Dienst wird, kommt das Netzwerk ins Spiel.

Neal Ford, Mark Richards, Pramod Sadalage und Zhamak Dehghani analysieren schwierige Entscheidungen zur Größe von Diensten, zu Daten, Verträgen und verteilten Prozessen. Das Buch lohnt sich, wenn mehrere vernünftige Lösungen unterschiedliche, erhebliche Kosten mitbringen. Es zeigt, wie du Kompromisse im Kontext eines konkreten Systems vergleichst. Buchbeschreibung beim Verlag.

Nehmen wir an, die Terminplanung hat inzwischen ein eigenes Team und bindet mehrere Partner an. Ein eigener Dienst kann diesem Team unabhängige Bereitstellungen ermöglichen. Gleichzeitig wird aus einem einfachen Methodenaufruf ein Vorgang, der sich verzögern, doppelt ausgeführt werden oder ohne Antwort enden kann. Die Geschäftsregel gilt weiterhin, aber die Bedingungen für ihre Durchsetzung haben sich geändert.

Outbox schließt eine konkrete Lücke. Für den gesamten Prozess braucht es weitere Entscheidungen.

Wenn wir einen Auftrag speichern und anschließend ein Ereignis versenden, kann der Prozess zwischen diesen beiden Vorgängen abbrechen. Der Datensatz bleibt erhalten, die Nachricht kommt nicht an. Das Muster Transactional Outbox speichert die fachliche Änderung und die Absicht zur Veröffentlichung in derselben lokalen Transaktion. Ein eigener Mechanismus veröffentlicht das Ereignis später. Broker oder Publisher können weiterhin ein Duplikat zustellen; der Empfänger muss darauf vorbereitet sein. Beschreibung von Outbox im Azure Architecture Center.

Beim Empfänger sollten das Speichern der Kennung des verarbeiteten Ereignisses und die fachliche Änderung eine gemeinsame lokale Transaktion bilden, mit einer Eindeutigkeitsbedingung für das Paar aus Empfänger und EventId. Vor dem Speichern lediglich zu prüfen, ob das Ereignis schon bekannt ist, reicht bei parallelen Nachrichten nicht aus. Soll die Wirkung in einem Aufruf einer externen API bestehen, braucht die sichere Wiederholung eine eigene Lösung, etwa einen vom Anbieter unterstützten Idempotenzschlüssel.

Wir brauchen auch eine Regelung für die Reihenfolge. Ein Ereignis mit Version 8 darf eine Projektion, die bereits Version 9 kennt, nicht unbemerkt zurücksetzen. Wir können Versionen prüfen und Lücken behandeln oder einen Mechanismus nutzen, der die Reihenfolge für den jeweiligen Auftrag sicherstellt. Die Wahl hängt vom Broker, von der Verarbeitung und davon ab, ob wir eine Reihenfolge für ein einzelnes Objekt oder eine größere Gruppe verlangen. Alles global zu ordnen kostet häufig mehr, als es nützt.

Saga und Kompensation: Was können wir tatsächlich rückgängig machen?

Nach der Ausgliederung von Lager und Terminplanung haben wir keine gemeinsame Transaktion mehr, die den gesamten Prozess umfasst. Wir können die lokalen Schritte mit einer Saga koordinieren. Scheitert die Reservierung des Einsatzteams, starten wir vereinbarte Ausgleichsmaßnahmen: Wir geben das Ersatzteil frei, speichern das Ergebnis und informieren die Auftragsbearbeitung. Auch eine Kompensation kann scheitern. Deshalb braucht sie dauerhaft gespeicherten Zustand, Wiederholungsversuche und einen Weg für manuelles Eingreifen. Das Saga-Muster in der Microsoft-Dokumentation.

Wir können weder die Zeit noch eine bereits gelesene Nachricht zurückdrehen. Was „Storniert“ bedeutet, muss mit dem Unternehmen vereinbart sein. Ist der Zustand einer externen Reservierung nach einem Timeout unbekannt, markieren wir sie nicht sofort als fehlgeschlagen. Zuerst klären wir das Ergebnis. Die Oberfläche sollte einen ehrlichen Wartezustand oder Prüfbedarf anzeigen, statt einen Abschluss zu versprechen.

05 / SITE RELIABILITY ENGINEERING

Architektur muss auch dem Menschen helfen, der nach einem Ausfall ans Telefon geht.

Das von Betsy Beyer, Chris Jones, Jennifer Petoff und Niall Richard Murphy herausgegebene Buch zeigt, wie sich Produktentwicklung mit der Verantwortung für den Betrieb verbinden lässt. Ein hilfreicher Einstieg sind SLI, SLO und das Fehlerbudget: Was messen wir, welches Niveau halten wir für ausreichend und wie reagieren wir, wenn wir es unterschreiten? Offizielle, kostenlose Ausgabe des Buches.

Für ServiceNord legen wir beispielhaft folgendes Ziel fest: In einem rollierenden Fenster von 28 Tagen erhalten mindestens 99,5% der ordnungsgemäß angenommenen Aufträge innerhalb von 120 Sekunden ein korrektes, dauerhaft gespeichertes Ergebnis. Das Ergebnis kann eine Bestätigung oder eine begründete Ablehnung sein. Ein Infrastrukturfehler wird nicht dadurch zu einem korrekten Ergebnis, dass wir ihn „Ablehnung“ nennen. Die Definition stimmen wir vor der Messung ab.

Dieses Budget zählt Vorgänge, keine Ausfallminuten. Wiederholungen desselben Vorgangs dürfen den Nenner nicht vergrößern. Außerdem müssen wir festlegen, wie wir Vorgänge behandeln, die kurz vor Ende des Beobachtungszeitraums angenommen wurden und noch keine vollen 120 Sekunden für ihren Abschluss hatten. Ohne diese Definition können zwei Teams nach bestem Wissen unterschiedliche Ergebnisse berechnen. SLI und SLO nach Google SRE.

Ein grüner Health-Endpunkt allein weist nicht nach, dass wir dieses Ziel erreichen. Wir brauchen Ereignisse für Beginn und Ende des Prozesses sowie übereinstimmende Kennungen. Ergänzend beobachten wir das Alter der ältesten Outbox-Nachricht, die Verzögerung beim Empfänger, die Anzahl prüfbedürftiger Zustände und erfolglose Kompensationen. Diese Signale sollen helfen, die Ursache zu finden. Sie ersetzen nicht die Messung der Nutzererfahrung.

Mit dem Budget verknüpfen wir eine zuvor vereinbarte Reaktion. Deutet die Fehlerrate darauf hin, dass das Budget schnell aufgebraucht sein wird, schränkt das Team riskante Releases ein, sucht nach der Ursache und verbessert die Zuverlässigkeit. Für dringende Fehlerbehebungen und Sicherheitsänderungen erfolgt eine eigene Risikobewertung. Die konkrete Regelung liegt beim Produkt und seinem Team; als Ausgangspunkt eignet sich die beispielhafte Regelung aus The Site Reliability Workbook.

Was sollte neben dem Code bereitliegen?

• Übersicht der Verantwortlichkeiten. Wer den Vorfall leitet und wer die einzelnen Teile des Prozesses kennt.
• Handlungsanleitung. Wie du einen Auftrag anhand seiner Kennung findest, einen sicheren Wiederholungsversuch erkennst und den Fall zur Prüfung weiterleitest.
• Wiederherstellungsplan. Eine Datenbanksicherung und ein geübtes Verfahren zur Wiederherstellung sowie zum Abgleich der Integrationszustände. Der Status „Backup erstellt“ allein ist kein Wiederherstellungstest.
• Bedingungen für die Bereitstellung. Kompatible Verträge und Migrationen, eine kontrollierte Inbetriebnahme sowie ein messbares Kriterium für den Abbruch der Bereitstellung.
• Erkenntnisse nach einem Vorfall. Was die Diagnose erschwert hat, welcher Schutz versagt hat und wie wir die Wirksamkeit der Korrektur prüfen.

Die Rückkehr zu einer früheren Anwendungsversion macht weder Datenänderungen noch Auswirkungen in einem externen System von selbst rückgängig. Den Notfallplan müssen wir deshalb anhand eines Szenarios mit der tatsächlichen Reihenfolge der Vorgänge prüfen, nicht nur mit einer leeren Testdatenbank.

WORKSHOP / VOM VERSTEHEN ZUR ENTSCHEIDUNG

Ordne den Ablauf. Begründe dann fünf Entscheidungen.

Wähle in der ersten Übung die Schritte in der richtigen Reihenfolge. Wir gehen von einem lokalen Speichervorgang für Auftrag und Outbox sowie einem getrennten Empfänger aus. Nachrichten können erneut zugestellt werden. Das Ergebnis der Übung bleibt in diesem Browsertab.

Wähle nach der Lektüre eine Entscheidung aus, die du in deinem System verbesserst.

Du musst nicht alle Muster auf einmal umsetzen. Beschreibe einen Prozess: Was nimmt er entgegen, wo speichert er den maßgeblichen Zustand, wie reagiert er auf Wiederholungen und woran erkennst du seinen Abschluss? Markiere die Stellen, an denen die Antwort heute nur geraten wird. Aus so einem Blatt entsteht oft ein besserer Arbeitsplan als aus einer Liste neuer Technologien.

Lesereihenfolge: Fundamentals hilft dir, Anforderungen und Kompromisse zu benennen. Bei Fowler findest du Muster, die zu deiner Logik passen. Domain-Driven Refactoring hilft beim Ordnen bestehenden Codes, The Hard Parts beim Trennen von Diensten und Daten und SRE dabei, aus Versprechen Messungen und tägliche Praxis zu machen. Kehre zum passenden Kapitel zurück, sobald eine konkrete Entscheidung ansteht.

Bücher und Quellen für die weitere Arbeit

Dies ist ein eigenständig verfasster Leitfaden zu Themen aus den genannten Publikationen und Dokumentationen. Die Links führen zu Autoren, Verlagen und offiziellen Materialien. Für die Übungen musst du die Bücher nicht kaufen.

1. Fundamentals of Software Architecture, 2nd Edition — Mark Richards, Neal Ford.
2. Patterns of Enterprise Application Architecture — Martin Fowler, mit den auf der Buchseite genannten Mitautoren.
3. Domain-Driven Refactoring — Alessandro Colla, Alberto Acerbis.
4. Software Architecture: The Hard Parts — Neal Ford, Mark Richards, Pramod Sadalage, Zhamak Dehghani.
5. Site Reliability Engineering — herausgegeben von Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy.

Ergänzend: Saga, Transactional Outbox, Service Level Objectives sowie Error Budget Policy.