Notification Domain
Benutzer über relevante Ereignisse zuverlässig und datenschutzgerecht informieren.
1. GeschäftsauftragGrundverständnis
Die Notification Domain übersetzt fachliche Events in verständliche Nachrichten und liefert sie über E-Mail, Push oder andere Kanäle aus. Sie darf den Bestellprozess nicht blockieren.
2. Domänenmodell und AggregateDDD
Das zentrale Aggregate heißt Notification. Es schützt Invarianten innerhalb einer Transaktion. Externe Komponenten arbeiten über Commands, Queries und Events, nicht über interne Tabellen.
| Aspekt | Festlegung | Begründung |
|---|---|---|
| Aggregate | Notification | Konsistenzgrenze der Fachregeln |
| Entity-ID | stabil und global eindeutig | ermöglicht Idempotenz und Korrelation |
| Value Objects | fachliche Werte statt primitive Strings | Validierung wird Teil des Modells |
3. ZustandsmodellLifecycle
Nur definierte Übergänge sind erlaubt. Jeder Übergang benötigt einen fachlichen Auslöser, Vorbedingungen, ein Ergebnis und einen nachvollziehbaren Audit-Kontext.
Event Flow verständlich gelesen
Ein Event ist mit einem eingeschriebenen Brief vergleichbar: Der Producer schreibt eine Nachricht, Kafka ordnet sie einem Topic und einer Partition zu, und Consumer lesen sie in ihrer eigenen Geschwindigkeit. Offsets markieren, bis wohin ein Consumer gekommen ist.
Alltagstaugliche Ablaufbeschreibung
Dieser Abschnitt beschreibt den Ablauf ohne unnötige Fachsprache. Er dient als Brücke zwischen dem sichtbaren Ergebnis und der technischen Umsetzung.
- Producer erstellt Event
- Schema wird geprüft
- Broker speichert Event
- Partition bestimmt Reihenfolge
- Consumer Group verteilt Arbeit
- Consumer bestätigt Offset
- Telemetrie misst Lag und Fehler.
Fachlicher Ablauf
Ein fachliches Ereignis informiert andere Bereiche darüber, dass sich etwas Relevantes geändert hat. Der sendende Bereich bleibt verantwortlich für seine Aussage; empfangende Bereiche entscheiden selbst, wie sie darauf reagieren.
- Fachliches Ziel: Der Ablauf liefert ein fachlich eindeutiges und für Benutzer beziehungsweise Betrieb nachvollziehbares Ergebnis.
- Verantwortung: Jeder beteiligte Bereich entscheidet nur innerhalb seiner eigenen fachlichen Zuständigkeit.
- Sichtbares Ergebnis: Order, Inventory, Payment und Notification können unabhängig reagieren, ohne eng gekoppelte synchrone Aufrufketten.
Technischer Ablauf
Der Producer schreibt ein Event in ein Topic. Partitionierung bestimmt Reihenfolge und Parallelität, Consumer Groups verteilen Arbeit, Offsets dokumentieren den Verarbeitungsstand. Retry, Idempotenz und Dead Letter Queue schützen vor Doppelwirkung und dauerhaft fehlerhaften Nachrichten.
- Daten und Schnittstellen: Daten werden an jeder Grenze validiert und nur über definierte APIs, Ports oder Events weitergegeben.
- Fehlerbehandlung: Fehler werden dort behandelt, wo ausreichender Kontext und Verantwortung vorhanden sind; Wiederholungen müssen sicher und nachvollziehbar bleiben.
- Technischer Nachweis: Geprüft werden Producer-Erfolg, Topic/Partition, Consumer Lag, Offset-Fortschritt, Retry-Zahl und DLQ-Einträge.
Zusammenspiel: Der fachliche Ablauf erklärt, warum etwas geschieht und welches Ergebnis zählt. Der technische Ablauf erklärt, wie dieses Ergebnis zuverlässig, sicher und beobachtbar umgesetzt wird.
4. Use CasesAnwendung
- PlanNotification: eigener Application Use Case mit Autorisierung, Validierung und idempotentem Ergebnis.
- SendNotification: eigener Application Use Case mit Autorisierung, Validierung und idempotentem Ergebnis.
- RetryDelivery: eigener Application Use Case mit Autorisierung, Validierung und idempotentem Ergebnis.
- SuppressNotification: eigener Application Use Case mit Autorisierung, Validierung und idempotentem Ergebnis.
Use Cases orchestrieren das Aggregate und Ports. Sie enthalten keine HTTP-, SQL- oder Kafka-Details.
5. API-VertragIntegration
POST /api/notifications
GET /api/notifications/{id}
POST /api/notifications/{id}/retry
POST /api/preferences6. Event ContractsMessaging
NotificationPlanned– unveränderliches vergangenes Ereignis mit eventId, occurredAt, aggregateId, schemaVersion und correlationId.NotificationSent– unveränderliches vergangenes Ereignis mit eventId, occurredAt, aggregateId, schemaVersion und correlationId.NotificationFailed– unveränderliches vergangenes Ereignis mit eventId, occurredAt, aggregateId, schemaVersion und correlationId.DeliveryConfirmed– unveränderliches vergangenes Ereignis mit eventId, occurredAt, aggregateId, schemaVersion und correlationId.
Events werden versioniert. Consumer müssen doppelte Zustellung tolerieren und unbekannte optionale Felder ignorieren.
7. Datenverantwortung und KonsistenzDaten
Eigene Daten: Vorlage, Kanal, Empfängerreferenz, Zustellstatus, Versuchszahl und Aufbewahrungsfrist. Inhalt nur soweit nötig.
Andere Domänen erhalten benötigte Informationen über API oder Event. Gemeinsame Tabellen und domänenübergreifende SQL-Joins werden vermieden. Für verteilte Abläufe gilt meist Eventual Consistency; der aktuelle Prozessstatus wird explizit sichtbar gemacht.
8. Sicherheit und DatenschutzSecurity
Empfängerpräferenzen und Einwilligungen werden respektiert. Sensible Daten gehören weder in Betreff noch in Push-Vorschau. Logs enthalten keine vollständigen Nachrichteninhalte.
- Least Privilege für Benutzer und Services.
- Auditierbare Statusänderungen.
- Minimierung personenbezogener Daten.
- Secrets nie in Code, Events oder Logs.
9. SLOs und BetriebszieleSRE
99 % transaktionale Nachrichten innerhalb von 60 Sekunden angenommen; Fehlerrate unter 0,5 %; Retry ohne Duplikate.
| Signal | Messung | Reaktion |
|---|---|---|
| Erfolg | fachlich erfolgreiche Use Cases | Error Budget und Release-Risiko bewerten |
| Latenz | p50/p95/p99 pro Use Case | Abhängigkeit und Warteschlange lokalisieren |
| Korrektheit | Invarianten und Reconciliation | Geschäftsschaden begrenzen |
10. Typische FehlerbilderTroubleshooting
- gleiche Nachricht mehrfach versendet
- Template passt nicht zum Ereignisstand
- Empfängeradresse veraltet
- Provider-Störung erzeugt unkontrollierte Retry-Welle
11. DiagnosewegBetrieb
- Betroffene Bestellung oder fachliche ID bestimmen.
- Correlation-ID über API, Event und Datenzustand verfolgen.
- Erwarteten und tatsächlichen Status vergleichen.
- Letzte erfolgreiche Transition und fehlgeschlagenen Schritt identifizieren.
- Idempotente, reversible Wiederherstellung wählen.
- Nach der Behebung Reconciliation und Benutzerwirkung prüfen.
12. Lernkontrolle und eigene NotizenSelbsttest
Erkläre die Verantwortung der Notification Domain ohne technische Produktnamen. Benenne zwei Invarianten, einen erlaubten Zustandsübergang und ein SLO.
Benachrichtigung: vollständiger Zusammenhang
Notification übersetzt fachliche Ereignisse in verständliche Nachrichten. Die Domäne entscheidet Kanal, Vorlage, Sprache und Zustellversuch, verändert aber niemals den Bestell- oder Zahlungszustand.
Wie funktioniert der Ablauf?Funktionsweise
Die Benachrichtigung-Domäne verarbeitet Befehle ausschließlich über ihre Anwendungsgrenze. Das Aggregat prüft Invarianten und erzeugt Events. Persistenz und Messaging sind Adapter. Andere Domänen kommunizieren über dokumentierte APIs oder Events und greifen nicht direkt auf interne Tabellen zu.
Konkretes CommerceOne-BeispielPraxis
Nach `PaymentAuthorized` erhält der Kunde eine Bestätigung. Ist der Mail-Provider nicht erreichbar, bleibt die Bestellung trotzdem bezahlt; Notification plant einen begrenzten Retry und macht den Zustellstatus sichtbar.
event: PaymentAuthorized
template: order-confirmed-de
channel: email
retry: exponential, max 5So liest du das Beispiel: Identitäten und Zustände werden ausdrücklich benannt. Wiederholung, Teilfehler und Beobachtbarkeit sind Teil des Designs. Das Beispiel ist zum Lesen und Anpassen gedacht; es wird nichts automatisch ausgeführt.
Entscheidungs- und DiagnosefragenReflexion
- Welches fachliche Ergebnis soll für den Benutzer entstehen?
- Welche Komponente besitzt die Verantwortung und welche Daten gehören ihr?
- Was passiert bei Timeout, Wiederholung oder Teilausfall?
- Welches Signal beweist, dass der Ablauf korrekt funktioniert?
- Welche einfachere Alternative wäre ausreichend?