Der Browser sendet Warenkorb, Lieferadresse und einen Idempotency-Key an das API Gateway. Der Benutzer erwartet eine schnelle, eindeutige Rückmeldung und darf durch Wiederholen der Anfrage keine doppelte Bestellung erzeugen.
CommerceOne Architekturgeschichte
Vom Klick zur bestätigten Bestellung
Der vollständige CommerceOne-Checkout vom Browser bis zur fachlichen Bestätigung.
0 % geöffnet
Bestellung vom Klick bis zur Bestätigung
Der Ablauf ähnelt einer Bestellung in einem gut organisierten Geschäft: Zuerst wird die Bestellung aufgenommen, dann fachlich geprüft, gespeichert und anschließend an Lager, Zahlung und Benachrichtigung weitergereicht. Nicht jeder Schritt muss in derselben Transaktion stattfinden.
Alltagstaugliche Ablaufbeschreibung
Dieser Abschnitt beschreibt den Ablauf ohne unnötige Fachsprache. Er dient als Brücke zwischen dem sichtbaren Ergebnis und der technischen Umsetzung.
- Kunde klickt „Bestellen“
- Gateway nimmt Anfrage an
- Order Service prüft Regeln
- PostgreSQL speichert Order und Outbox
- Kafka verteilt Event
- Inventory und Payment reagieren
- Notification informiert den Kunden.
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.
1. Benutzer startet den Checkout
2. Identität und Berechtigung werden geprüft
Das Gateway validiert das Access Token. Der Order Service prüft zusätzlich, ob der angemeldete Benutzer für den Warenkorb handeln darf. Authentifizierung beantwortet, wer der Benutzer ist; Autorisierung entscheidet, was er tun darf.
3. Die Domäne entscheidet
Der Order Service lädt keine fremden Tabellen, sondern führt einen Use Case in der Order-Domäne aus. Das Aggregate prüft Mengen, Preise, Status und fachliche Invarianten.
4. Bestellung und Outbox werden atomar gespeichert
Order und Outbox-Eintrag werden in derselben PostgreSQL-Transaktion geschrieben. Erst nach erfolgreichem Commit gilt die Bestellung intern als angelegt.
5. Ereignis wird veröffentlicht
Ein Publisher liest offene Outbox-Einträge, sendet OrderCreated an Kafka und markiert den Eintrag erst nach erfolgreicher Bestätigung. Wiederholungen bleiben möglich und müssen durch Idempotenz beherrscht werden.
6. Nachgelagerte Domänen reagieren
Inventory reserviert Bestand, Payment startet die Zahlungsautorisierung und Notification bereitet eine Nachricht vor. Jede Domäne besitzt eigene Daten und verarbeitet das Ereignis unabhängig.
7. Benutzer erhält einen stabilen Status
Der Browser erhält eine Order-ID und einen nachvollziehbaren Status. Lang laufende Folgeschritte werden nicht künstlich in eine synchrone Anfrage gepresst.
Architekturentscheidung
CommerceOne wählt eine kurze synchrone Annahme plus asynchrone Folgeprozesse. Dadurch bleibt der Checkout reaktionsfähig, während Bestand, Zahlung und Benachrichtigung unabhängig skalieren und wiederholt werden können.
Lernkontrolle
An welcher Stelle muss Idempotenz fachlich erzwungen werden, damit ein Retry keine zweite Bestellung erzeugt?
Antwort selbst formulieren
Weiterlernen
Öffne markierte Fachbegriffe direkt im Text oder untersuche ihre Beziehungen im Knowledge Graph.