Definiert Komponenten, Grenzen, Daten- und Steuerfluss, Schnittstellen und Fehlerbehandlung für Microservices. Diese Referenz legt die Übernahmegrenze, das Fehlerverhalten und beobachtbare Nachweise fest, während umgebungsspezifische Grenzen konfigurierbar bleiben.
Paketstatus: Referenzkontext bereit für menschliche Überprüfung. Der Vertrag und die Testszenarien sind vollständig, es wird jedoch nicht behauptet, dass eine übernehmende Implementierung diese bestanden hat.
Entscheidung
Für Microservices wird eine aufgezeichnete Architekturentscheidung mit eigenen Schnittstellen und Abhängigkeitsrichtung übernommen. Verwenden Sie eine eigene Grenze, ein explizites Zustandsmodell und versionierte Schnittstellen; halten Sie Richtlinienentscheidungen getrennt von Adaptern und Seiteneffekten. Dieses Paket ist ein Referenzvertrag: Das übernehmende Team muss numerische Grenzen, Anbieter, Rechtsräume und operative Eigentümer anhand von Nachweisen in seiner eigenen Umgebung wählen.
Umfang
- Die Microservices-Akteure, Eingaben, Ausgaben, Zustände, Richtlinien- oder Schemaversionen und extern sichtbare Ergebnisse, die durch diesen Architekturblock beschrieben werden.
- Primäre und alternative Schnittstellen, Hintergrundarbeiten, Caches, Integrationen, Supportpfade und Nachweise, die dieselbe Grenze beanspruchen können.
- Übernahmespezifische Konfiguration, Rollout, Wiederherstellung und Verifikationsverantwortlichkeiten, die für eine sichere Anwendung der Referenz erforderlich sind.
Außerhalb dieses Blocks
- Die Wahl eines universellen Anbieters, Frameworks, Rechtsraums, numerischen Schwellenwerts, Aufbewahrungszeitraums oder Service-Level-Objectives für jeden Übernehmer.
- Die Behauptung, dass verpackte Szenarien gegen eine nachgelagerte Implementierung ausgeführt wurden oder dass diese Referenz rechtliche, Sicherheits- oder Barrierefreiheitszertifizierungen gewährt.
Vertrag
- Benennen Sie die Entscheidungsfaktoren, Alternativen, Einschränkungen, Umkehrbarkeit und Bedingungen, die die gewählte Struktur ungültig machen würden.
- Weisen Sie Daten-, Verhaltens-, Schnittstellen-, Bereitstellungs- und Betriebsverantwortung an jeder Grenze zu; gemeinsamer Code hebt die Eigentümerschaft nicht auf.
- Erlauben Sie Abhängigkeiten nur in der dokumentierten Richtung und tauschen Sie stabile Verträge statt des internen Modells einer anderen Komponente aus.
- Definieren Sie Timeout-, Kapazitäts-, Konsistenz-, Degradations-, Bereitstellungs-, Migrations- und Wiederherstellungsverhalten für jede entfernte oder asynchrone Grenze.
- Dokumentieren Sie Komponentenbesitz und erlaubte Abhängigkeitsrichtung, einschließlich welcher Daten jede Grenze überschreiten dürfen.
- Sorgen Sie dafür, dass synchrone, asynchrone und Batch-Pfade dieselbe Autorität und Zustandsinvarianten implementieren.
- Übernehmen Sie Servicegrenzen nur dort, wo unabhängiger Besitz, Skalierung, Zuverlässigkeit, Sicherheit oder Bereitstellungswert die Kosten eines verteilten Systems überwiegen.
- Beginnen Sie mit einem End-to-End-Slice und beweisen Sie Beobachtbarkeit, Kompatibilität, Datenbesitz, Fehlerisolation und Wiederherstellung, bevor Sie weiter zerlegen.
Implementierungsanleitung
- Beginnen Sie mit dem Domänenzustand und Schnittstellenvertrag, dann fügen Sie Adapter, Speicher, Warteschlangen und anbieter-spezifischen Code hinzu.
- Modellieren Sie Microservices-Eingaben, -Ausgaben, Akteure, Zustände, Invarianten, Seiteneffekte und Nachweise, bevor Sie Framework- oder Anbieter-Details auswählen.
- Speichern Sie die anwendbare Microservices-Vertrags- oder Richtlinienversion mit materiellem Zustand, damit Migrationen, Wiedergabe und Supportentscheidungen zuordenbar bleiben.
- Führen Sie den Pfad hinter kontrolliertem Rollout ein, vergleichen Sie erwartete und beobachtete Ergebnisse und behalten Sie einen getesteten Wiederherstellungspfad, bis Übernahmenachweise vollständig sind.
Fehlerbehandlung und Schutzmaßnahmen
- Ein Grenzfehler bleibt enthalten, erzeugt ein stabiles Aufrufergebnis und verfügt über einen getesteten Rollback- oder Vorwärts-Wiederherstellungspfad.
- Ungültiger oder widersprüchlicher Microservices-Zustand wird abgelehnt oder isoliert; die Implementierung schätzt niemals einen Wert, der Autorität erweitert oder einen Effekt dupliziert.
- Wiederholungen sind begrenzt und verwenden dauerhafte Identität; nach Erschöpfung erreicht die Arbeit einen überprüfbaren Endzustand mit verantwortlichem Eigentümer.
Verifikation und Betrieb
- Üben Sie den Vertrag über jeden Adapter aus und beweisen Sie, dass eine fehlgeschlagene Abhängigkeit die autoritative Grenze nicht umgehen kann.
- Überwachen Sie Microservices-Erfolg, Ablehnung, Validierungsfehler, Abhängigkeitsfehler, Wiederholungsermüdung und Wiederherstellung nach Vertragsversion ohne sensible Nutzlastdimensionen.
- Führen Sie gepaarte positive und negative Fixtures nach Richtlinien-, Schema-, Abhängigkeits-, Migrations- oder Grenzänderungen erneut aus und bewahren Sie die resultierenden Nachweise auf.
Übernahmeannahmen
- Namen und Werte im Beispiel sind ein konkretes Fixture, keine universellen Standardwerte; Übernehmer ersetzen sie durch dokumentierte Nachweise und Eigentum.
- Das übernehmende System kann authentifizierte Identität, dauerhafte Betriebs- oder Aufzeichnungs-Versionen, begrenzte Telemetrie und einen kontrollierten Änderungsweg bereitstellen.
Die ausführbar aussehenden Beispiele in diesem Paket sind Fixtures und Akzeptanzverträge. Führen Sie den Sammlungsvalidator aus, um Struktur und Metadaten zu prüfen, übersetzen und führen Sie dann die Szenarien im Ziel-Repository aus, bevor Sie Implementierungsnachweise aufzeichnen.