Einen lokalen Cloud-Emulator bauen, der mit offiziellen SDKs und CLIs funktioniert

## Anfrage- und Antwortformate der echten Cloud vor Abkürzungen stellen Setzen Sie folgende Prioritäten: 1. Kompatibilität mit dem Cloud-Protokoll der Ursprungsplattform; 2. das von offiziellen SDK- und CLI-Clients erwartete Verhalten; 3. die Wiederverwendung vorhandener Emulatormuster; 4. Korrektheit vor Bequemlichkeit; 5. eng begrenzte, testbare Änderungen. Fügen Sie nicht aus Gründen einer bequemeren Implementierung eigene Endpunktstrukturen hinzu und vereinfachen Sie dafür keine Anfrage- oder Antwortformate. Nehmen Sie keine weitreichende Umstrukturierung vor, sofern das geforderte Verhalten sie nicht erfordert. Bestimmen Sie vor der Bearbeitung den Dienst, seine Rolle auf der Steuerungs- oder Datenebene, die Protokollfamilie, die als Vorlage dienende vorhandene Implementierung, die Auswirkungen auf Konfiguration, Speicherung und Dokumentation sowie den kleinsten sinnvollen Prüfplan. Wenn das Verhalten unklar ist, hat zunächst der Vertrag der Ursprungsplattform Vorrang, danach das etablierte Emulatorverhalten und schließlich die Erwartungen der Kompatibilitätstestsammlung. Würde die Aufgabe eine dienstübergreifende Architekturänderung erfordern, legen Sie die Abwägungen offen, statt blind umzustrukturieren. ## Protokoll-Handler schlank halten und Geschäftslogik in die Dienste legen Verwenden Sie einen geschichteten Dienstentwurf: - Steuerkomponenten oder Anfragebearbeiter analysieren die Protokolleingabe und erzeugen protokollkompatible Antworten; - Dienste enthalten die Geschäftslogik und lösen die gemeinsam genutzte Cloud-Domänenausnahme aus; - Modelle bilden Domänendaten ab; - Register, Konfiguration, Speicherfabriken, Lebenszyklusdienste, Parser, Erzeuger und Ausnahmezuordner stellen die gemeinsame Infrastruktur bereit. Halten Sie Steuerkomponenten schlank. Verwenden Sie gemeinsame Hilfsfunktionen wieder und übernehmen Sie die Struktur des ähnlichsten etablierten Dienstes, bevor Sie ein neues Muster einführen. Leiten Sie Domänenfehler über den gemeinsamen Ausnahmetyp weiter. Abfrage- und XML-Abläufe sollten den üblichen Ausnahmezuordner verwenden; JSON-Protokollabläufe sollten den erforderlichen strukturierten Fehlerinhalt zurückgeben. Die Rückgabetypen der Steuerkomponenten müssen mit den Reflexions- und Serialisierungsbeschränkungen der Vorabkompilierung vereinbar bleiben. Verwenden Sie Konstruktorinjektion, geschweifte Klammern für Bedingungsanweisungen und selbsterklärenden Quelltext. Lassen Sie einen `catch`-Block niemals leer; wird eine Ausnahme absichtlich toleriert, protokollieren Sie genügend Kontext für die Diagnose. ## Vor jeder neuen Operation das echte Protokoll des Dienstes ermitteln Bestimmen Sie das tatsächliche Übertragungsprotokoll, bevor Sie einen Vorgang hinzufügen: - Abfrageprotokolle verwenden formularcodierte Aktionen und XML-Antworten; - Protokolle nach Art von JSON RPC verwenden eine Zielkopfzeile und strukturiertes JSON; - REST JSON und REST XML verwenden Ressourcenpfade mit ihrem jeweiligen nativen Nachrichtenkörperformat; - Dienste der Datenebene können native TCP-Proxys anstelle von HTTP-Verwaltungs-APIs erfordern. Verwenden Sie den gemeinsamen XML-Erzeuger, XML-Parser und die Namensraumkonstanten. Analysieren Sie XML niemals mit regulären Ausdrücken. Richten Sie JSON-Fehler an der Fehlerstruktur des Zielprotokolls aus. Einige Dienste bieten mehr als einen Kompatibilitätspfad. Halten Sie alternative Anfragebearbeiter aufeinander abgestimmt und prüfen Sie sie gemeinsam. Behandeln Sie Endpunkte zur Identitätsermittlung entsprechend ihrem tatsächlichen offenen Protokoll, statt sie in das Modell der Verwaltungs-API zu zwingen. Prüfen Sie Verwaltungs-APIs mit offiziellen SDK-Clients und nicht nur mit manuell erstellten HTTP-Anfragen. Eine manuell akzeptierte Nutzlast beweist nicht, dass Clientserialisierung, Kopfzeilen, Fehler, Paginierung oder URL-Erzeugung kompatibel sind. ## Speichermodi und Konfigurationsdateien immer gemeinsam ändern Unterstützen Sie Speicherung über die gemeinsame Fabrik und die festgelegten Modi; erzeugen Sie niemals direkt innerhalb eines Dienstes eine Instanz einer Speicherimplementierung. Beachten Sie die Lebenszyklus-Hooks für Laden, Pufferleeren, Prüfpunkte oder Write-ahead-Verhalten. Wenn Schnittstellenvorgaben und bereitgestellte Werte voneinander abweichen, behandeln Sie die Laufzeitkonfigurationsdatei des Projektarchivs als maßgebliche Quelle. Für speicherbezogenes Verhalten: 1. aktualisieren Sie die maßgebliche Konfigurationsschnittstelle; 2. aktualisieren Sie die Hauptlaufzeitkonfiguration; 3. aktualisieren Sie die Prüfkonfiguration; 4. binden Sie den Modus über die Speicherfabrik ein; 5. prüfen Sie die Einbindung in den Lebenszyklus. Aktualisieren Sie bei jeder nutzerseitigen Konfiguration auch die Dokumentation und befolgen Sie die etablierte Benennungskonvention für Umgebungsvariablen. Prüfen Sie Basis-URL, Rechnernamen, Standardwerte für Region und Konto, Anschlussbereiche, Stammverzeichnisse der dauerhaften Speicherung und Containernetzwerke, wenn sie erzeugte Kennungen oder Endpunkte beeinflussen. Fügen Sie neue Felder kompatibel hinzu und halten Sie gemeinsame Konfiguration, Speicherung und Dienstregistrierung aufeinander abgestimmt. ## Kompatibilität mit offiziellen SDKs testen, nicht mit manuellen Anfragen Verwenden Sie Unit-Tests für isoliertes Dienstverhalten und Integrationstests für Protokollverarbeitung, dauerhafte Speicherung und den für Clients sichtbaren Zustand. Eine geordnete Ausführung von Integrationstests ist nur zulässig, wenn das Verhalten absichtlich zustandsbehaftet ist. Jede Änderung an Analyse, Antwortstruktur, Fehlern, Semantik der dauerhaften Speicherung, URL-Erzeugung, Dienstaktivierung oder alternativen Protokollpfaden erfordert automatisierte Testabdeckung. Führen Sie während der Bearbeitung zunächst einen gezielten Test und danach die unmittelbar relevante Testsammlung aus. Nutzen Sie das Kompatibilitätsprojekt, wenn eine Änderung das tatsächliche SDK-Verhalten beeinflussen kann. Bevorzugen Sie SDK-basierte Zusicherungen gegenüber unmittelbaren HTTP-Anfragen und dokumentieren Sie jede beabsichtigte Abweichung von der Ursprungsplattform. Wenn alternative Protokollpfade denselben Vorgang bereitstellen, prüfen Sie sie auf gleichwertige Semantik. Bleibt Zustand dauerhaft erhalten, prüfen Sie das Lade- und Pufferleerungsverhalten für die betreffenden Speichermodi. Leiten Sie Kompatibilität nicht allein aus manuellen Anfragen ab. Wenn sich Verhalten ohne automatisierte Testabdeckung geändert hat, erläutern Sie den fehlenden Test und warum er nicht hinzugefügt werden konnte. ## Neue Dienste vollständig fertigstellen, ohne nebenbei die Freigabeabläufe zu ändern Wenn Sie einen Dienst hinzufügen, erstellen Sie seine Steuerkomponente, seinen Dienst und seine Modelle; registrieren Sie ihn; ergänzen Sie die maßgebliche Konfiguration und die Prüfkonfiguration; binden Sie die Speicherung über die Fabrik an; fügen Sie Tests hinzu; und aktualisieren Sie die Dokumentation. Vor dem Abschluss: - führen Sie die relevanten Tests und Protokollkompatibilitätsprüfungen aus; - bestätigen Sie, dass keine eigenen Endpunkte oder nur der Bequemlichkeit dienenden Übertragungsformate eingeführt wurden; - prüfen Sie Aktualisierungen an Konfiguration, Speicherung, Lebenszyklus und Dokumentation; - prüfen Sie erzeugte URLs und Ressourcenkennungen auf Einheitlichkeit; - halten Sie die Protokollierung in häufig durchlaufenen Pfaden strukturiert und zurückhaltend. Halten Sie Änderungsanträge eng umrissen, bewahren Sie bestehendes Verhalten, sofern keine Änderung ausdrücklich gefordert ist, und trennen Sie sachfremde Umstrukturierungen ab. Verwenden Sie gebräuchliche Commit-Typen und ausschließlich menschliche Urheberschaft. Behandeln Sie Freigabezweige, Kennzeichnungen und Veröffentlichungsabläufe als kritische Infrastruktur. Das Zusammenführen in den Entwicklungszweig allein beweist keine stabile Freigabe. Ändern Sie beim Implementieren von Dienstfunktionen das Freigabeverhalten nicht nebenbei.