Zahlung ohne globale Transaktion
Eine Zahlung ist wie eine Überweisung mit mehreren beteiligten Stellen: Der Order Service fordert die Zahlung an, der Payment Service verarbeitet sie und meldet das Ergebnis zurück. Jeder Service führt nur seine eigene lokale Transaktion aus.
Alltagstaugliche Ablaufbeschreibung
Dieser Abschnitt beschreibt den Ablauf ohne unnötige Fachsprache. Er dient als Brücke zwischen dem sichtbaren Ergebnis und der technischen Umsetzung.
- Order erstellt Zahlungsauftrag
- Event oder API-Aufruf erreicht Payment
- Payment prüft Idempotency Key
- Provider wird angesprochen
- Ergebnis wird gespeichert
- Payment Event aktualisiert Order.
Fachlicher Ablauf
Ein Kunde möchte eine Bestellung zuverlässig abschließen. Fachlich müssen Preis, Bestand, Zahlung und Bestellstatus zusammenpassen, auch wenn einzelne Schritte zeitversetzt erfolgen oder ein Teilsystem vorübergehend ausfällt.
- 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: Der Kunde sieht eine eindeutige Bestätigung oder einen nachvollziehbaren Zwischenstatus, niemals eine unklare Doppelbuchung.
Technischer Ablauf
Der Request erreicht das Gateway und den Order Service. Das Aggregate prüft Regeln, PostgreSQL speichert den lokalen Zustand, die Transactional Outbox hält das Event in derselben Transaction fest und Kafka verteilt es an Inventory, Payment und Notification. Correlation IDs verbinden Logs und Traces über alle Stationen.
- 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 Idempotency Key, Transaction Boundary, Outbox-Verarbeitung, Event-Status und End-to-End-Trace.
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.
Change-Impact-Prüfung
Eine Änderung an einem Wissensknoten kann Code, Learning Paths, Betrieb, Beziehungen und andere Kapitel beeinflussen. Diese Seite zeigt die verbindliche Prüfreihenfolge.
Beispiel: Kafka-Vertrag ändern
- Betroffene Beziehung Order → Kafka identifizieren.
- Event-Schema und Outbox-Code prüfen.
- Inventory-, Payment- und Notification-Konsumenten bewerten.
- Lernmodule und Praxisaufgaben anpassen.
- Dashboards, Alerts und Runbooks auf neue Felder oder Fehlerbilder prüfen.
- Threat Model und Datenschutz prüfen.
- Modell und generierte Sichten neu validieren.
Impact-Matrix
| Änderung | Mindestens prüfen |
|---|---|
| Domänenregel | API, Events, Tests, Lernziele |
| Event-Vertrag | Producer, Consumer, Schema, Observability |
| SLO | Dashboard, Alert, Runbook, Error Budget |
| Security-Regel | Identity, Gateway, Code, Threat Model |
| Ordner oder URL | Modell, Links, Navigation, Checks |