Event-Driven Architecture vertieft
Domain Events, Kafka, JMS, Outbox, Schema Evolution, Ordering, Replay und DLQ.
Version 3IntegrationCodeDiagramm
In dieser Datei
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
| Entscheidung | Gute Praxis | Prüffrage |
|---|---|---|
| Fachliche Grenze | Zuerst Use Case, Invariante und Verantwortlichkeit klären. | Welche Geschäftsentscheidung wird geschützt? |
| Technische Grenze | Framework-/Library-Code hinter Port, Adapter oder Konfiguration kapseln. | Kann die Domain ohne Framework getestet werden? |
| Betrieb | Timeouts, 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
| Stolperfalle | Warum gefährlich |
|---|---|
| Event zu klein | Consumer müssen synchron nachladen. |
| Event zu groß | Interne Modelle werden gekoppelt. |
| Kein Schema-Konzept | Consumer brechen bei harmlosen Änderungen. |