robust-architecture

Robuste Architektur

Erstellen Sie den kleinstmöglichen Entwurf, dessen Garantien erklärt und hinterfragt werden können. Regeln leiten Entscheidungen; sie bescheinigen keine Korrektheit. Eine nützliche Architektur macht wichtige Fakten explizit, gibt Regeln eine autoritative Heimat und bleibt verständlich, wenn etwas fehlschlägt oder sich ändert.

Von einer Konsequenz ausgehen

Überprüfen Sie für ein bestehendes System die tatsächlichen Einstiegspunkte, Aufrufer, Zustandsspeicher und Prüfungen, bevor Sie Diagrammen oder früheren Vorschlägen vertrauen. Beschreiben Sie für ein neues System den ersten realen Ablauf, bevor Sie Komponenten auswählen, und unterscheiden Sie dabei Anforderungen von Annahmen.

Halten Sie nur Einschränkungen fest, die eine Entscheidung ändern: Benutzer und Berechtigungen, Betriebsvolumen, Latenz- oder Ressourcenbudgets, Verfügbarkeit, Fehlerbedingungen, Wiederherstellungs- und Haltbarkeitsanforderungen, Bereitstellungszwänge und das, was das Team betreiben kann. Fragen Sie nach der fehlenden Produktentscheidung, wenn sie die Korrektheit ändert. Führen Sie unabhängige, umkehrbare Arbeiten fort, während diese Entscheidung ungelöst ist.

Kalibrieren Sie den Eingriff:

• Modell-/Verantwortungslücke: Die notwendige Tatsache, vollständige Operation oder konsistente Autorität fehlt oder ist aufgeteilt. Lösen Sie diesen Vertrag, bevor Sie seine Leser flicken.
• Grenzdefekt: Ein adäquater Eigentümer existiert, aber ein Aufrufer umgeht ihn oder seine Durchsetzung ist unvollständig. Vertiefen oder nutzen Sie diesen Eigentümer; ein Defekt über mehrere Ebenen hinweg erfordert nicht automatisch eine neue Architektur.
• Produktlücke: Das erforderliche Verhalten ist unentschieden. Präsentieren Sie die konkrete Konsequenz und die kleinstmöglichen Entscheidungen, anstatt stillschweigend zu wählen.
• Darstellungs-/lokaler Defekt: Korrekte zugrundeliegende Fakten benötigen eine lokale Darstellungs-, Parsing- oder Kopierkorrektur. Wenden Sie die normale lokale Reparatur an; beenden Sie hier den Architektur-Workflow.

Eine große Datei, doppelte Syntax, ein fehlender Mustername oder ein vorgeschlagener Paketname ist für sich genommen kein Beleg für eine Modellücke.

Wenden Sie bei Entwürfen oder Überprüfungen, die Zugriff auf geschützte Ressourcen betreffen, die Autorisierung an, falls installiert. Sie besitzt den Zugriffsrichtlinien-Walkthrough; behalten Sie die lokalen Eigentums- und Vertrauensregeln unten bei, wenn Sie diese Skill allein verwenden.

Fakten und Regeln eine Heimat geben

Benennen Sie die Tatsache oder Invariante, ihre logische Autorität und die Operationen, die sie ändern dürfen. Autorität kann eine lokale Funktion, ein Datei-Publisher, ein Library-Handle, ein Prozess oder Dienst sein; sie muss kein Server oder neues Modul sein.

• Platzieren Sie die Regel an dem Punkt, der sie für jeden relevanten Produzenten durchsetzen kann. Eintrittsadapter etablieren Vertrauen zum Aufrufer, parsen Eingaben, rufen diesen Eigentümer auf und übersetzen das Ergebnis. Nützliche frühe Prüfungen verbessern das Feedback; autoritative Prüfungen schützen den tatsächlichen Effekt.
• Modellieren Sie, wer gemeinsame Daten besitzt, explizit. Ein fehlender Eltern- oder Bereichswert ist nicht automatisch globale Autorität. Wenden Sie die tatsächliche Richtlinie des Akteurs auf Lesevorgänge, Serialisierung und Effekte an, nicht nur auf sichtbare Kontrollen.
• Trennen Sie aktuelle Beziehungen, unveränderliche Ereignisfakten und Projektionen. Speichern Sie die Historie oder den Snapshot, den die Funktion tatsächlich benötigt. Aktuelle Beziehungen können fehlende vergangene Fakten nicht rekonstruieren; markieren Sie unbekannte Legacy-Historie ehrlich.
• Geben Sie einem Wiederholungsversuch seine Operationsidentität. Zwei identische Nutzlasten können unterschiedliche Absichten sein. Definieren Sie Schlüsselbereich, fehlerhafte Wiederverwendung, Aufbewahrung und Wiederholung unter aktueller Autorität, wenn die Korrektheit von Wiederholungen wichtig ist.
• Geben Sie abgeleiteten Regeln und Darstellungen eine einzige gewartete Definition, auf die sich Konsumenten einigen müssen. Bewahren Sie beabsichtigte Unterschiede zwischen Zielgruppen, Kohorten, Einheiten und Zeitbedeutungen. Behalten Sie billige lokale Darstellungsduplikate bei, wenn das Teilen eine künstliche Abhängigkeit schaffen würde.
• Explizit spezifizierte Multi-Writer- oder Offline-Designs sind gültig. Benennen Sie Konfliktsemantiken, Koordination und Partitionsverhalten, anstatt anzunehmen, dass ein einzelner physischer Schreiber immer aufgezwungen werden kann.

Eine Grenze verdient ihre Existenz, indem sie eine Entscheidung verbirgt und Wissen von Aufrufern entfernt. Überprüfen Sie dies direkt: Welcher Aufrufer kennt nach der Änderung die Regel, das Speicherlayout oder die Sequenzierung nicht mehr? Ein Wrapper, der jeden Aufrufer die gleichen Geschäftsschritte koordinieren lässt, hat das Eigentum nicht verschoben.

Das vollständige Ergebnis besitzen

Verfolgen Sie eine Absicht durch ihre wichtigen Effekte. Geben Sie an, was zusammenhängen muss, den autoritativen Abschlusspunkt und was der Benutzer erhält, wenn die Ausführung vor oder nach diesem Punkt stoppt.

Zählen Sie jede beobachtbare Veröffentlichung auf, einschließlich Caches und Hintergrund-Callbacks. Identifizieren Sie für asynchrone Arbeit die Operation, Identität, Version und Lebensdauer, zu der ein Ergebnis gehört, und prüfen Sie die Anwendbarkeit an jeder relevanten Veröffentlichungsgrenze. Eine späte Sichtprüfung kann einen früheren Cache oder Speicherschreibvorgang nicht schützen. Unterscheiden Sie das Abbrechen eines Konsumenten vom Rückgängigmachen eines bereits festgeschriebenen Geschäftseffekts.

Verwenden Sie ein tatsächliches atomares Primitiv für Invarianten, die Unteilbarkeit innerhalb einer Autorität erfordern. Wenn gleichzeitige Schreiber eine vorherige Lesung ungültig machen können, erzwingen Sie anwendbaren Bereich, Zustand und Version im Effekt oder einer äquivalenten Serialisierung. Passen Sie den Mechanismus an eine erreichbare Verschachtelung an; eine single-threaded reine Transformation benötigt keine Datenbank-konkurrierenden Mechaniken.

Lesen Sie an Netzwerk-, Prozess-, Datei- oder asynchronen Grenzen Grenzprüfungen. Wählen Sie den relevanten Zweig: dauerhafte Effekte, Ressourcenlebensdauer, Echtzeitarbeit oder Zustand/Historie. Eine lokale Transaktion macht einen externen Effekt nicht atomar; ein unbekanntes Ergebnis ist nicht unbedingt ein Fehler. Definieren Sie Wiederherstellung und wahrheitsgemäße ausstehende/teilweise Ergebnisse, bevor Sie Wiederholungsversuche hinzufügen.

Machen Sie für wiederverwendbare APIs Eingaben, Ausgaben, Ablehnungen, Eigentum und Bereinigungsverantwortlichkeiten explizit. Bewahren Sie aussagekräftige Fehler-/Kontrollflussunterschiede. Platzieren Sie Diagnosen dort, wo ein Fehler erklärt werden kann, ohne geschützte Daten preiszugeben; ein Log ist kein Wiederherstellungsmechanismus oder eine Autorisierungs-/Historiendatenbank.

Eine proportionale Struktur wählen

Bevorzugen Sie das vorhandene kohärente Modul und die unterstützten Plattformmechanismen. In einer neuen kleinen Anwendung können wenige gut abgegrenzte Funktionen oder Module ausreichen. Trennen Sie die Bereitstellung oder führen Sie Infrastruktur ein, wenn eine konkrete Anforderung unabhängige Skalierung, Fehlerisolation, Laufzeitbeschränkungen oder organisatorisches Eigentum benötigt. Respektieren Sie eine explizit gewählte Plattform, während Sie einen folgenreichen Kompromiss erläutern.

Bewerten Sie die kleinste Änderung neben einer plausiblen Alternative. Erklären Sie den wichtigen Unterschied in Korrektheit, Ressourcen-/Betriebskosten und Umkehrbarkeit. Behalten Sie jede Designentscheidung in einem Zuhause; extrahieren Sie nur stabile, nützliche Nähte unabhängig. Physische Ordner, Pakete und Dienste folgen bewährten Grenzen, anstatt den Beweis zu liefern.

Bewahren Sie die gesamte Invariante über eine Änderung der Platzierung hinweg. Migration und Rollout müssen bestehende Daten, alte/neue Schreiber, öffentliche Konsumenten und Rollback-Kompatibilität berücksichtigen. Die Entfernung einer Spalte, API oder Ressource erfordert den Nachweis, dass ihre Verpflichtungen und Konsumenten beendet sind.

Versuchen Sie, sie zu widerlegen

Wählen Sie einen dünnen vertikalen Ausschnitt, der die umstrittene Grenze übt. Verwenden Sie den tatsächlichen Speicher-, Datei-, Protokoll- oder Ressourcen-naht, der für die Behauptung relevant ist; isolieren Sie nur echte externe Abhängigkeiten. Geben Sie für einen frühen Entwurf ohne Implementierung das unterscheidende Experiment an und lassen Sie sein Ergebnis unbekannt.

Fordern Sie die Invariante mit den relevanten Fehlern heraus: falsche Autorität, veralteter Zustand, wiederholte oder umsortierte Arbeit, ein Absturz an der Abschlussgrenze, Abbruch, fehlende/mehrdeutige Historie und die tatsächliche Last- oder Zeitbegrenzung. Verwenden Sie explizite Lockvögel und kontrollierte Verschachtelungen oder Uhren, wenn sie die Regel unterscheiden. Ein Test sollte fehlschlagen, wenn diese Regel entfernt wird, nicht nur gemockte Aufrufe zählen oder gewählte Namen erkennen.

Überprüfen Sie Sicherheit und Fortschritt: wie eine gültige Operation schließlich abgeschlossen oder eine ehrliche Ablehnung gegeben wird; wie ausstehende Arbeit wiederhergestellt wird; wie Speicher, Warteschlangen, Verbindungen und Latenz begrenzt bleiben. Wählen Sie diese Prüfungen aus der Betriebshülle, anstatt jeden theoretischen Fehler zu proben.

Beobachten Sie den gemounteten/Benutzer- oder öffentlichen Bibliotheksfluss, wenn Sie behaupten, dass er funktioniert. Unit-Assertions, Diagramme, grüne Wiederholungen, Benchmark-Schätzungen und synthetische Fixtures etablieren nur ihre eigene getestete Grenze. Trennen Sie gemessene Ergebnisse, Quellenbefunde, Annahmen, fehlende Entscheidungen und nicht ausgeführte Beweise.

Eine überprüfbare Entscheidung liefern

Skalieren Sie die Ausgabe auf die Entscheidung. Liefern Sie für einen substanziellen Entwurf:

1. Den konkreten Ablauf, Einschränkungen und wichtige Unbekannte.
2. Die Invarianten, benannten Autoritäten und betroffenen Produzenten/Konsumenten.
3. Zustand/Historie, Vertrauen, Abschluss- und Fehlergrenzen, mit ausreichenden Verträgen, um einen Erfolg und einen Fehler zu verfolgen.
4. Die gewählte kleine Struktur, eine relevante Alternative und warum der Kompromiss passt.
5. Eine erste Scheibe mit beobachtbaren Akzeptanz-, Wiederherstellungs- und Evolutions-/Rollout-Prüfungen.
6. Was bereit ist, was eine Produktentscheidung oder einen Beweis benötigt und was tatsächlich verifiziert wurde.

Verwenden Sie ein kleines Diagramm nur, wenn es eine Grenze klarer macht. Überspringen Sie leere Vorlagenabschnitte für eine lokale Reparatur. Bewahren Sie den Umfang des Benutzers: Eine Entwurfs-/Überprüfungsanfrage erzeugt eine Entscheidung, keine Erlaubnis zu implementieren, migrieren, bereitzustellen, zu veröffentlichen oder Live-Daten zu ändern.

Wenn Sie diese Skill übernehmen oder bewerten, lesen Sie Evaluierungsprotokoll. Der primäre Hintergrund ist in Grundlagen aufgeführt; er informiert das Denken, anstatt ein einzelnes Design zu validieren.