Domänenübergreifendes event‑modellieren: konkrete Patterns, um inkonsistenzen bei synchronen und asynchronen flows zu vermeiden

In Integrationsprojekten begegnet mir immer wieder dasselbe Problem: Domänenübergreifende Events werden unklar modelliert, führen zu Inkonsistenzen zwischen synchronen und asynchronen Flows und verursachen lange Fehlersuchen. In diesem Beitrag teile ich praktische Patterns und Erfahrungen, die helfen, solche Fallen zu vermeiden — konkret, umsetzbar und erprobt in Projekten mit Banking-, Healthcare- und Industrie-Integrationen.

Warum domänenübergreifendes Event‑Modellieren so schwierig ist

Häufige Fragen, die mir Kunden stellen, sind: Was gehört ins Event? Soll das Event das «volle» Domain‑Model transportieren? Wie unterscheiden wir Intent von Fact? Was passiert bei Rollbacks in synchronen Calls, wenn asynchrone Prozesse bereits ausgelöst wurden?

Die Schwierigkeit entsteht, weil Events eine Schnittstelle zwischen unterschiedlichen Verantwortlichkeiten sind: ein Produzent (Domain A) publiziert, Konsumenten (Domain B, C) reagieren unabhängig. Das führt zu Spannungen zwischen:

• Konsistenzanforderungen (synchron strong vs. eventual consistency)
• Verantwortungsgrenzen (wer ist Source of Truth?)
• Technischer Implementierung (REST, gRPC, EventBus, Kafka, RabbitMQ usw.)

Pattern 1 — Clear Fact vs Intent Separation

Ein zentraler Fehler ist, Intent (Absicht) und Fact (eingetretenes Ereignis) zu vermischen. Ich setze deshalb konsequent zwei Event‑Arten ein:

• Intent Events (z. B. OrderPlacedRequest): werden synchron oder asynchron gesendet, weisen eine Absicht aus, sind aber kein bestätigter Zustand.
• Fact Events (z. B. OrderPlaced): signalisieren, dass ein Zustand eingetreten ist — Source of Truth bestätigt.

Vorteil: Konsumenten reagieren nur auf Facts, um Inkonsistenzen zu vermeiden. Intents dienen als Trigger für Workflows und erlauben Validierung oder Ablehnung, bevor Facts publiziert werden.

Pattern 2 — Minimal Viable Event (MVE)

Frage: Welche Daten gehören ins Event? Meine Faustregel: so wenig wie möglich, so viel wie nötig.

• Primärschlüssel / Referenzen (IDs)
• Unveränderliche Metadaten (Timestamp, Source, EventType, Version)
• Domain‑relevante Fakten, nicht das komplette Aggregat

Wenn mehr Kontext benötigt wird, verweise ich auf das Source‑System via Link/HATEOAS oder bdaten‑Service (z. B. ein Anfrage‑API). Das reduziert Payload, verhindert leaky abstractions und hält Events resilient gegenüber Modelländerungen.

Pattern 3 — Event‑Versionierung und Schema Registry

Schemaänderungen sind unvermeidbar. Ich nutze Schema Registries (z. B. Confluent Schema Registry für Avro/Protobuf) und semantische Versionierung für Events:

• Major: Breaking change
• Minor: Erweiterung mit Backward Compatibility
• Patch: nicht‑semantische Korrekturen

Vor allem bei domainübergreifenden Konsumenten ist eine Registry hilfreich, damit Teams frühzeitig Breaking Changes erkennen und Migrationspfade planen können.

Pattern 4 — Idempotenz und deduplizierung

In asynchronen Flows sind doppelte Events normal (z. B. bei Retries). Konsumenten müssen idempotent sein:

• Use‑Case: Orders → Payment → Shipping. Wenn Payment‑Event mehrfach empfangen wird, darf kein doppelter Zahlungsauftrag ausgelöst werden.
• Technik: deduplizierende IDs, idempotente HTTP‑Endpoints, transactional outbox patterns.

Ich empfehle die Kombination: transactional outbox beim Produzenten + deduplizierungs‑Tabelle beim Konsumenten. Das reduziert Chancen für Doppelverarbeitung ohne starke Kopplung.

Pattern 5 — Sagas für verteilte Transaktionen

Ein häufiges Problem ist die Koordination von Schritten über mehrere Domänen. Sagas (orchestrierte oder choreografierte) sind hier das Mittel der Wahl:

• Choreografie: lose Kopplung, jeder Service reagiert auf Events; gut für einfache Flows.
• Orchestrierung: zentraler Saga‑Orchestrator steuert Kompensation; besser bei komplexen Rollback‑Szenarien.

Wichtig ist, Kompensationslogik als eigenständige, getestete Schritte zu modellieren und Komplexität sichtbar zu machen (z. B. via Saga‑Daten‑Log/Trace).

Pattern 6 — Hybrid Flows: Synchorn vs Asynchron entscheiden

Bei Architekturentscheidungen höre ich oft: «Alles asynchron ist die Lösung». Das stimmt nicht immer. Ich prüfe folgende Kriterien, um zu entscheiden:

• Benötigte Antwortzeit (latency SLAs)
• Transaktionale Konsistenzanforderungen
• Fehlerbehandlung und Rückmeldungen an den Nutzer

Praxisbeispiel: Ein Checkout‑Flow kann synchron für die Zahlungsautorisierung bleiben, aber Fulfillment und Benachrichtigungen werden asynchron über Events gesteuert. So haben wir eine gute UX ohne Konsistenzverlust.

Pattern 7 — Contract Testing und Consumer‑Driven Contracts

Wenn mehrere Teams Events konsumieren, schaffen Consumer‑Driven Contracts (CDC) Sicherheit. Tools wie Pact funktionieren gut für HTTP, für Events nutze ich:

• Contract Tests gegen Schema Registry
• Provider‑Verifizierungstools, die Event‑Beispiele prüfen

Regelmäßige Contract‑Checks im CI verhindern Überraschungen beim Deploy.

Technische Bausteine, die ich einsetze

Je nach Kontext kombiniere ich folgende Technologien:

Operationalisierung: Monitoring, Tracing, und SLAs

Events leben in der Laufzeit — deshalb sind Observability und SLAs keine Nice‑to‑have:

• End‑to‑End Tracing (Zipkin, Jaeger) zeigt, wo Flows stocken.
• Business‑Metriken (z. B. Orders pro Minute, Zeit bis Fact) messen reale Auswirkungen.
• Alerting auf Latenz‑ und Fehlerraten verhindert eskalierende Inkonsistenzen.

Häufige Fragen, kurz beantwortet

• Sollten Events das komplette Domain‑Objekt enthalten? Nein. Referenzen + minimale Fakten. Erweiterungen über Query‑APIs.
• Wie verhindere ich Inkonsistenzen bei synchronen Calls? Klare Trennung: synchrone Calls für Immediate Consistency, asynchrone Facts für eventual consistency; Sagas bei Mehrschritt‑Transaktionen.
• Wer sollte Events versionieren? Der Produzent pflegt die Schema‑Version, Konsumenten validieren. Eine Registry macht Änderungen sichtbar.

Wenn Sie möchten, kann ich Ihr bestehendes Event‑Schema reviewen, konkrete MVE‑Beispiele aus Ihrem Domain‑Model erstellen oder einen Workshop zur Implementierung von Sagas und idempotenten Konsumenten moderieren. Schreiben Sie mir mit Ihrem Use Case — ich helfe gern beim konkreten Design und bei der Umsetzung.