Kapitel II · Bereich 07 von 12
Die Frage an unseren ShopMuss der Checkout warten, bis die Rechnung als PDF fertig ist?
Hier erfährst du, wie Systemteile Daten austauschen und zuverlässig zusammenarbeiten.
9 Bausteine
Hier anfangenAPI-VerträgeWas wird zugesagt, und wer kommt herein?
Lager sagt Reservierung R-77 für B-1042 zu; das Feld expiresAt kommt kompatibel hinzu.
Wartet der Aufrufer auf die Antwort?
Bestellung fragt Lager direkt; Rechnung nimmt den Auftrag an, BestellungBezahlt geht an Versand und Analyse.
Was passiert bei Wiederholung und Fehlern?
pay-B-1042 verhindert doppelte Belastung; die Outbox hält BestellungBestaetigt, bis der Kanal wieder erreichbar ist.
Bekannte Namen – und wo sie stecken
API-Verträge legen Zusagen fest. Synchrone und asynchrone Kommunikation nutzen sie, Queues und Pub/Sub verteilen Nachrichten. Idempotenz sichert Wiederholungen, Outbox die Veröffentlichung, Orchestrierung führt Abläufe. Gateway steuert den Zugang, Versionierung die Weiterentwicklung.
Hier klärst du im Shop, ob der Checkout auf die Rechnung warten muss, was Aufrufer zugesagt bekommen und wie Wiederholungen und Änderungen verlässlich bleiben. Jeder Baustein zeigt sein Thema an unserem Shop.
Das lernst duDu kannst Pflichtfelder, Ergebniszustände und Fehler einer Lagerreservierung als Vertrag benennen.
Im ShopBestellung reserviert über den Vertrag des Lagermoduls zwei Tassen für B-1042. Die Reservierung besitzt eine stabile Kennung und ein Ablaufdatum.
API-Verträge öffnenDas lernst duDu kannst im Checkout markieren, bei welchen Aufrufen der Bestellablauf unmittelbar auf eine Antwort wartet.
Im ShopIm modularen Monolithen fragt Bestellung Lager und Zahlung direkt an. Das Zahlungsmodul ruft den externen Zahlungsanbieter über das Netzwerk auf.
Synchrone Kommunikation öffnenDas lernst duDu kannst Annahme, spätere Verarbeitung und sichtbaren Status eines Rechnungsauftrags trennen.
Im ShopNach bestätigter Bestellung nimmt Rechnung einen Auftrag an und erstellt den Beleg später. Der Checkout muss nicht auf das fertige PDF warten.
Asynchrone Kommunikation öffnenDas lernst duDu kannst Queue, Pub/Sub und Stream für drei konkrete Shop-Aufgaben passend zuordnen.
Im ShopDer Shop verarbeitet Rechnungsaufträge, verteilt BestellungBezahlt an Versand und Analyse und bewahrt Bestellstatusänderungen für spätere Auswertung auf.
Queues, Pub/Sub & Streams öffnenDas lernst duDu kannst vorhersagen, wann wiederholte Zahlungsaufrufe dieselbe oder eine neue fachliche Wirkung auslösen.
Im ShopDas Zahlungsmodul sendet B-1042 mit dem Schlüssel pay-B-1042 an den externen Anbieter. Die erste Antwort geht verloren.
Idempotenz öffnenDas lernst duDu kannst zeigen, wie Bestellung und Veröffentlichungsauftrag gemeinsam gespeichert und später getrennt versendet werden.
Im ShopVariante mit dauerhaftem Nachrichtenkanal: Bestellung bestätigt B-1042 und speichert zugleich BestellungBestaetigt in ihrer Outbox. Der Nachrichtenkanal ist kurzzeitig nicht erreichbar.
Transactional Outbox öffnenDas lernst duDu kannst für Reservierung und Zahlung unterscheiden, wo Ablaufwissen bei Orchestrierung und Choreografie liegt.
Im ShopVariante: Lager und Zahlung sind unabhängige Dienste. Das Team vergleicht eine Bestellorchestrierung mit einer ereignisgetriebenen Choreografie; der Zahlungsanbieter bleibt extern.
Orchestrierung & Choreografie öffnenDas lernst duDu kannst externe Shop-Routen über ein API-Gateway den zuständigen internen Zielen zuordnen.
Im ShopVariante: Katalog und Versand wurden aus belegten Betriebsgründen als Dienste getrennt. Browser und Kundenservice greifen ausschließlich über das API-Gateway auf Shop-Routen zu.
Gateway, Mesh & Discovery öffnenDas lernst duDu kannst eine kompatible API-Erweiterung von einer brechenden Bedeutungsänderung unterscheiden.
Im ShopDas Lagermodul erweitert die Reservierungsantwort um expiresAt. Später soll das bisherige Feld available von einer Zahl zu einer fachlichen Verfügbarkeitsstufe wechseln.
API-Versionierung öffnenDiese Bereiche hängen fachlich direkt mit Kommunikation & APIs zusammen.