Event-Driven Architecture vertieft

Domain Events, Kafka, JMS, Outbox, Schema Evolution, Ordering, Replay und DLQ.

Version 3IntegrationCodeDiagramm
Diagramm Event-Driven Architecture vertieft
Fachlich-technische Darstellung zu Event-Driven Architecture vertieft.

Event ist eine fachliche Tatsache

Ein Event beschreibt, was passiert ist: OrderPlaced, PaymentReserved, InvoiceCreated. Es ist kein technischer Dump einer Datenbankzeile.

Outbox als Zuverlässigkeitsmuster

Datenänderung und Event-Erfassung werden in derselben Datenbanktransaktion gespeichert. Ein Publisher publiziert später zuverlässig an Broker oder Streaming-Plattform.

Consumer sind eigenständige Systeme

Consumer brauchen Idempotenz, Schema-Toleranz, Monitoring, Retry-Strategie und Dead Letter Queue. Ein Event macht Integration nicht automatisch einfach.

Entscheidungen

EntscheidungGute PraxisPrüffrage
Fachliche GrenzeZuerst Use Case, Invariante und Verantwortlichkeit klären.Welche Geschäftsentscheidung wird geschützt?
Technische GrenzeFramework-/Library-Code hinter Port, Adapter oder Konfiguration kapseln.Kann die Domain ohne Framework getestet werden?
BetriebTimeouts, Logs, Metriken, Traces, Security und Rollback definieren.Wie erkennt der Betrieb Fehler rechtzeitig?

Ausführliche Beispiele

Domain Event mit Version
public record OrderPlacedEvent(
    UUID eventId,
    UUID orderId,
    String customerNumber,
    BigDecimal totalAmount,
    Instant occurredAt,
    int schemaVersion
) {}
Idempotenter Consumer
public void onOrderPlaced(OrderPlacedEvent event) {
    if (processedEvents.exists(event.eventId())) {
        return;
    }
    billingService.createInvoice(event.orderId());
    processedEvents.markProcessed(event.eventId());
}

Typische Stolperfallen

StolperfalleWarum gefährlich
Event zu kleinConsumer müssen synchron nachladen.
Event zu großInterne Modelle werden gekoppelt.
Kein Schema-KonzeptConsumer brechen bei harmlosen Änderungen.
⌂ Cockpit