Definiert eine kontrollierte Ereignistaxonomie mit Geschäftsvorfällen, stabilen Identitäten, typisierten Eigenschaften, Kontextgrenzen, Versionierung, Datenschutzzweck und Datenqualitätsverantwortung für konsistente Messungen.
Paketstatus: Referenzkontext bereit für menschliche Überprüfung. Der Vertrag und die Testszenarien sind abgeschlossen, es wird jedoch nicht behauptet, dass eine übernehmende Implementierung diese bestanden hat.
Entscheidung
Benennen Sie Ereignisse als vergangenheitsbezogene Geschäftsvorfälle und trennen Sie sie von veränderlicher Interpretation. Registrieren Sie jedes Ereignis und jede Eigenschaft vor der Produktion, verwenden Sie gemeinsamen Kontext nur für wirklich universelle Felder und versionieren Sie semantisch brechende Änderungen.
Umfang
- Benennung, Vorkommenssemantik, Produzent, Subjekt, Ereignisidentität, Zeit, Kontext, Eigenschaften, Enums, Versionen, Zweck, Datenschutzklasse, Eigentum und Qualität.
- Produkt- und Betriebsanalyseereignisse, die von Produzenten und Konsumenten geteilt werden.
- Ein Register, das Validierung und Dokumentation steuert.
Außerhalb dieses Blocks
- Metrikdefinitionen, die nachgelagert abgeleitet werden oder UI-Steuerungsnamen in permanente Ereignisse übernehmen.
- Jedes verfügbare Entitätsattribut in jedes Ereignis einfügen.
Vertrag
- Jedes Ereignis repräsentiert ein abgeschlossenes oder beobachtetes Vorkommnis und benennt Produzent, Auslöser, Subjekt, Akteursrolle, wenn erlaubt, sowie Erfolgs-/Fehlersemantik.
- Ereignis-ID ist pro Vorkommnis eindeutig; Wiederholungen bewahren sie, während mehrere unterschiedliche Vorkommnisse unterschiedliche IDs verwenden.
- Vorkommenszeit und Empfangszeit sind getrennt; Zeitstempel verwenden einen eindeutigen Standardzeitpunkt.
- Eigenschaften haben Typ, erlaubte Werte, Bedeutung von Null/Abwesenheit, Einheit, Datenschutzklasse, Zweck und Eigentümer.
- Entitätskennungen sind stabil und pseudonym, sofern die Analyse keine direkte Identität erfordert.
- Semantisch oder typbedingt brechende Änderungen erzeugen eine neue Ereignisversion; additive optionale Felder folgen der Kompatibilitätsrichtlinie.
Implementierungsleitfaden
- Übernehmen Sie einen gemeinsamen Envelope und ein registergestütztes Payload-Schema.
- Halten Sie Umgebung, Release, Produzent, Schema-Version, Einwilligungs-/Zweckprofil und Testverkehrsmarkierung im kontrollierten Kontext.
- Validieren Sie bei Produzenten-CI und Ingestion; isolieren Sie inkompatible Payloads statt sie zu erzwingen.
- Definieren Sie kanonische Beispiele und Gegenbeispiele für mehrdeutige Ereignisse.
Fehlerbehandlung und Schutzmaßnahmen
- Unbekannter Ereignistyp oder erforderliche Eigenschaft schlägt Validierung fehl und wird isoliert.
- Ist das Ergebnis eines Vorkommnisses unbekannt, verwenden Sie einen expliziten Zustand oder unterlassen Sie die Emission gemäß Vertrag; setzen Sie niemals standardmäßig Erfolg.
- Wird eine Kennung versehentlich wiederverwendet, bewahren Sie Belege und korrigieren Sie nachgelagerte Zählungen durch eine versionierte Reparatur.
Verifikation und Betrieb
- Messen Sie Schema-Ablehnung, unbekannte Enums, doppelte Ereignis-IDs, verspätete Ankunft, fehlende Eigenschaften, Produzentenversionabdeckung und Ereignisvolumenunterbrechungen.
- Weisen Sie jeder Ereignisversion Eigentümer und Auslaufdatum zu.
- Stimmen Sie kritische Vorkommenszählungen mit operativen Quellen ab.
Die ausführbar aussehenden Beispiele in diesem Paket sind Fixtures und Akzeptanzverträge. Führen Sie
python tools/validate.py vom Sammlungsstamm aus, um Paketstruktur und Metadaten zu prüfen; implementieren und führen Sie dann die Szenarien im Ziel-Repository aus.
Annahmen zur Übernahme
- Namen und numerische Werte in
example.yamlsind ein Übernahmeprofil, keine universellen Standardwerte. - Das übernehmende Team muss Akteure, Datenklassen, Fehler-Vokabular und Eigentum auf sein System abbilden.