Gemeinsame Use Cases

Der verbindliche funktionale Umfang für alle drei Projekte – vollständig, nummeriert und architekturneutral.

Java 2110 Use Cases36 Regeln36 SzenarienOfflinefähig

Schnellnavigation

UC-01
Kunde registrierenUC-02
Produkt registrierenUC-03
Bestellung aufgebenUC-04
Bestand reservierenUC-05
Zahlung autorisierenUC-06
Rechnung erzeugenUC-07
Versand vorbereitenUC-08
Benachrichtigung sendenUC-09
Bestellung stornierenUC-10
Zahlungsfehler behandeln

Gemeinsame Use Cases

Diese Spezifikation ist für alle drei späteren Implementierungen verbindlich. Architektur und technische Struktur dürfen variieren; fachliche Ergebnisse, Regeln und Fehlerbedeutungen nicht.

ID Use Case Primärakteur Erfolgsereignis
UC-01 Kunde registrieren Customer Service oder Self-Service-Kanal CustomerRegistered
UC-02 Produkt registrieren Catalog Manager ProductRegistered
UC-03 Bestellung aufgeben Kunde oder Order-Entry-Mitarbeiter OrderPlaced
UC-04 Bestand reservieren Order Process Manager InventoryReserved
UC-05 Zahlung autorisieren Order Process Manager PaymentAuthorized
UC-06 Rechnung erzeugen Billing Process Handler InvoiceIssued
UC-07 Versand vorbereiten Fulfillment Process Handler ShipmentPrepared
UC-08 Benachrichtigung senden Notification Handler NotificationSent
UC-09 Bestellung stornieren Kunde oder Customer Service OrderCancellationRequested
UC-10 Zahlungsfehler behandeln Payment Recovery Handler PaymentRetryScheduled

UC-01 – Kunde registrieren

Primärakteur Customer Service oder Self-Service-Kanal
Auslöser Eine neue natürliche oder juristische Person möchte Bestellungen aufgeben.
Ergebnis Ein aktiver Kunde mit stabiler CustomerId ist gespeichert.

Vorbedingungen

  • Es liegt noch kein aktiver Kunde mit derselben normalisierten E-Mail-Adresse vor.
  • Die Pflichtangaben Name und E-Mail-Adresse wurden übermittelt.

Eingaben

  • Name
  • E-Mail-Adresse
  • optionale Rechnungs- und Lieferadresse
  • optionale externe Referenz

Geschäftsregeln

  • BR-CUS-001 Die normalisierte E-Mail-Adresse ist innerhalb des Customer-Bestands eindeutig.
  • BR-CUS-002 Ein Kunde wird mit dem Status ACTIVE angelegt, sofern keine fachliche Sperre vorliegt.
  • BR-CUS-003 E-Mail-Adresse und Adressen werden vor Speicherung fachlich validiert.

Normalablauf

  1. Registrierungsdaten entgegennehmen.
  2. Pflichtfelder und Formate prüfen.
  3. Eindeutigkeit der E-Mail-Adresse prüfen.
  4. Kundenidentität erzeugen.
  5. Kundenprofil speichern.
  6. CustomerRegistered veröffentlichen.

Fehlerfälle

  • CUSTOMER_EMAIL_ALREADY_EXISTS Ein aktiver Kunde mit derselben normalisierten E-Mail-Adresse existiert bereits.
  • CUSTOMER_DATA_INVALID Mindestens ein Pflichtfeld oder Format ist ungültig.

Fachliche Ereignisse

  • CustomerRegistered

Verbindliche Szenarien

  • AC-CUS-001 Erfolgreiche Kundenregistrierung
  • AC-CUS-002 Doppelte E-Mail-Adresse wird abgelehnt
  • AC-CUS-003 Ungültige E-Mail-Adresse wird abgelehnt

UC-02 – Produkt registrieren

Primärakteur Catalog Manager
Auslöser Ein verkaufbares Produkt soll in den Katalog aufgenommen werden.
Ergebnis Ein aktives Produkt ist mit ProductId und SKU im Katalog verfügbar.

Vorbedingungen

  • Die SKU ist im Katalog noch nicht vergeben.
  • Preis, Bezeichnung und Währung liegen vor.

Eingaben

  • SKU
  • Produktbezeichnung
  • Preis
  • Währung
  • optionale Beschreibung

Geschäftsregeln

  • BR-CAT-001 Die SKU ist dauerhaft eindeutig und wird nach Veröffentlichung nicht umgedeutet.
  • BR-CAT-002 Der Verkaufspreis muss größer als null sein.
  • BR-CAT-003 Neu registrierte Produkte sind standardmäßig ACTIVE und bestellbar.

Normalablauf

  1. Produktdaten entgegennehmen.
  2. SKU normalisieren und Eindeutigkeit prüfen.
  3. Money-Wert validieren.
  4. ProductId erzeugen.
  5. Produkt speichern.
  6. ProductRegistered veröffentlichen.

Fehlerfälle

  • PRODUCT_SKU_ALREADY_EXISTS Die SKU ist bereits vergeben.
  • PRODUCT_PRICE_INVALID Preis oder Währung ist ungültig.

Fachliche Ereignisse

  • ProductRegistered

Verbindliche Szenarien

  • AC-CAT-001 Produkt mit gültigem Preis registrieren
  • AC-CAT-002 Doppelte SKU wird abgelehnt
  • AC-CAT-003 Nicht positiver Preis wird abgelehnt

UC-03 – Bestellung aufgeben

Primärakteur Kunde oder Order-Entry-Mitarbeiter
Auslöser Ein aktiver Kunde bestätigt einen Warenkorb.
Ergebnis Eine Bestellung im Status PLACED mit unveränderlichen Preis-Snapshots ist gespeichert.

Vorbedingungen

  • Der Kunde ist ACTIVE.
  • Alle referenzierten Produkte sind ACTIVE.
  • Der Warenkorb enthält mindestens eine Position.

Eingaben

  • CustomerId
  • Bestellpositionen mit ProductId und Quantity
  • Lieferadresse
  • IdempotencyKey

Geschäftsregeln

  • BR-ORD-001 Eine Bestellung besitzt mindestens eine Position mit positiver Menge.
  • BR-ORD-002 Preis und Produktbezeichnung werden als unveränderlicher Bestell-Snapshot übernommen.
  • BR-ORD-003 Ein IdempotencyKey darf für denselben Auftrag nur ein Ergebnis erzeugen.
  • BR-ORD-004 Nur aktive Kunden und aktive Produkte dürfen verwendet werden.

Normalablauf

  1. Kunde, Produkte und Eingaben prüfen.
  2. IdempotencyKey prüfen.
  3. Bestellpositionen mit Preis-Snapshots erzeugen.
  4. Gesamtsumme berechnen.
  5. OrderId vergeben und Status PLACED setzen.
  6. Bestellung speichern.
  7. OrderPlaced veröffentlichen.

Fehlerfälle

  • CUSTOMER_NOT_ACTIVE Der Kunde ist unbekannt oder nicht aktiv.
  • PRODUCT_NOT_ORDERABLE Mindestens ein Produkt ist nicht bestellbar.
  • ORDER_LINES_INVALID Warenkorb ist leer oder enthält ungültige Mengen.
  • IDEMPOTENCY_CONFLICT Der Schlüssel wurde mit abweichenden Nutzdaten erneut verwendet.

Fachliche Ereignisse

  • OrderPlaced

Verbindliche Szenarien

  • AC-ORD-001 Gültige Bestellung wird aufgegeben
  • AC-ORD-002 Leerer Warenkorb wird abgelehnt
  • AC-ORD-003 Preis wird als Snapshot übernommen
  • AC-ORD-004 Idempotente Wiederholung erzeugt keine zweite Bestellung

UC-04 – Bestand reservieren

Primärakteur Order Process Manager
Auslöser OrderPlaced wurde für eine neue Bestellung empfangen.
Ergebnis Alle Positionen sind atomar reserviert oder die Bestellung ist unverändert geblieben.

Vorbedingungen

  • Die Bestellung befindet sich im Status PLACED.
  • Für jede Position existiert ein verwalteter Bestand.

Eingaben

  • OrderId
  • Positionen mit ProductId und Quantity
  • ReservationId

Geschäftsregeln

  • BR-INV-001 Eine Reservierung darf verfügbaren Bestand niemals unter null reduzieren.
  • BR-INV-002 Alle Positionen werden atomar reserviert oder vollständig abgelehnt.
  • BR-INV-003 Dieselbe ReservationId ist idempotent.
  • BR-INV-004 Freigegebene Reservierungen erhöhen den verfügbaren Bestand genau einmal.

Normalablauf

  1. Bestellstatus und ReservationId prüfen.
  2. Verfügbaren Bestand aller Positionen ermitteln.
  3. Gesamtreservierung atomar entscheiden.
  4. Bestände und Reservierung speichern.
  5. Bestellung auf INVENTORY_RESERVED setzen.
  6. InventoryReserved veröffentlichen.

Fehlerfälle

  • INSUFFICIENT_STOCK Mindestens eine Position ist nicht vollständig verfügbar.
  • RESERVATION_CONFLICT Die ReservationId wurde mit anderen Positionen verwendet.
  • ORDER_STATE_INVALID Die Bestellung ist nicht reservierbar.

Fachliche Ereignisse

  • InventoryReserved
  • InventoryReservationRejected

Verbindliche Szenarien

  • AC-INV-001 Alle Positionen werden atomar reserviert
  • AC-INV-002 Teilreservierung ist ausgeschlossen
  • AC-INV-003 Parallele Reservierungen erzeugen keinen negativen Bestand
  • AC-INV-004 Idempotente Wiederholung verändert Bestand nicht erneut

UC-05 – Zahlung autorisieren

Primärakteur Order Process Manager
Auslöser InventoryReserved wurde empfangen.
Ergebnis Eine erfolgreiche Autorisierung ist genau einmal gespeichert oder ein eindeutig klassifizierter Fehler liegt vor.

Vorbedingungen

  • Die Bestellung befindet sich im Status INVENTORY_RESERVED.
  • Bestellsumme und Zahlungsreferenz sind vorhanden.

Eingaben

  • OrderId
  • Zahlungsreferenz
  • Betrag
  • Währung
  • PaymentId

Geschäftsregeln

  • BR-PAY-001 Der Autorisierungsbetrag muss exakt der offenen Bestellsumme entsprechen.
  • BR-PAY-002 PaymentId und Provider-Idempotency-Key verhindern doppelte Belastungen.
  • BR-PAY-003 Eine stornierte oder bereits bezahlte Bestellung darf nicht erneut autorisiert werden.
  • BR-PAY-004 Fachliche Ablehnung und technischer Providerfehler werden unterschiedlich behandelt.

Normalablauf

  1. Bestellstatus und Betrag prüfen.
  2. Idempotency-Daten prüfen.
  3. Payment Provider aufrufen.
  4. Autorisierung und Provider-Referenz speichern.
  5. Bestellung auf PAYMENT_AUTHORIZED setzen.
  6. PaymentAuthorized veröffentlichen.

Fehlerfälle

  • PAYMENT_DECLINED Der Provider lehnt die Zahlung fachlich ab.
  • PAYMENT_AMOUNT_MISMATCH Betrag oder Währung stimmt nicht mit der Bestellung überein.
  • PAYMENT_PROVIDER_UNAVAILABLE Der Provider ist technisch nicht erreichbar.
  • ORDER_STATE_INVALID Die Bestellung ist nicht zahlbar.

Fachliche Ereignisse

  • PaymentAuthorized
  • PaymentDeclined
  • PaymentAuthorizationDeferred

Verbindliche Szenarien

  • AC-PAY-001 Zahlung wird erfolgreich autorisiert
  • AC-PAY-002 Abweichender Betrag wird vor Provideraufruf abgelehnt
  • AC-PAY-003 Fachliche Ablehnung wird nicht technisch wiederholt
  • AC-PAY-004 Wiederholung belastet nicht doppelt

UC-06 – Rechnung erzeugen

Primärakteur Billing Process Handler
Auslöser PaymentAuthorized wurde empfangen.
Ergebnis Eine unveränderliche Rechnung ist eindeutig der Bestellung zugeordnet.

Vorbedingungen

  • Die Bestellung ist PAYMENT_AUTHORIZED.
  • Es existiert noch keine Rechnung für die Bestellung.

Eingaben

  • OrderId
  • Kunden- und Rechnungsadresse
  • Bestell-Snapshot
  • Zahlungsreferenz

Geschäftsregeln

  • BR-BIL-001 Pro Bestellung existiert höchstens eine aktive Rechnung.
  • BR-BIL-002 Rechnungsnummern sind eindeutig und nach Ausstellung unveränderlich.
  • BR-BIL-003 Rechnungspositionen und Summen stammen aus dem Bestell-Snapshot, nicht aus aktuellen Katalogdaten.

Normalablauf

  1. Zahlungs- und Bestellstatus prüfen.
  2. Vorhandene Rechnung prüfen.
  3. Rechnungsnummer vergeben.
  4. Rechnungs-Snapshot erzeugen.
  5. Rechnung speichern.
  6. InvoiceIssued veröffentlichen.

Fehlerfälle

  • INVOICE_ALREADY_EXISTS Für die Bestellung existiert bereits eine aktive Rechnung.
  • BILLING_DATA_INCOMPLETE Notwendige Rechnungsdaten fehlen.
  • ORDER_STATE_INVALID Die Bestellung ist noch nicht abrechenbar.

Fachliche Ereignisse

  • InvoiceIssued

Verbindliche Szenarien

  • AC-BIL-001 Rechnung wird nach Zahlungsautorisierung erstellt
  • AC-BIL-002 Doppelte Rechnung wird verhindert
  • AC-BIL-003 Rechnung verwendet Bestell-Snapshot

UC-07 – Versand vorbereiten

Primärakteur Fulfillment Process Handler
Auslöser InvoiceIssued und PaymentAuthorized liegen vor.
Ergebnis Ein Versandauftrag mit unveränderlichem Adress-Snapshot ist vorbereitet.

Vorbedingungen

  • Bestand ist reserviert.
  • Zahlung ist autorisiert.
  • Lieferadresse ist vollständig.
  • Die Bestellung ist nicht storniert.

Eingaben

  • OrderId
  • Lieferadresse
  • reservierte Positionen
  • optionale Versandpräferenz

Geschäftsregeln

  • BR-FUL-001 Versand darf erst nach Bestandreservierung und Zahlungsautorisierung vorbereitet werden.
  • BR-FUL-002 Pro Bestellung darf höchstens ein aktiver Versandauftrag existieren.
  • BR-FUL-003 Die Lieferadresse wird als Versand-Snapshot übernommen.

Normalablauf

  1. Voraussetzungen prüfen.
  2. Vorhandenen Versandauftrag prüfen.
  3. ShipmentId erzeugen.
  4. Versand-Snapshot speichern.
  5. Bestellung auf READY_FOR_SHIPMENT setzen.
  6. ShipmentPrepared veröffentlichen.

Fehlerfälle

  • SHIPMENT_ALREADY_EXISTS Ein aktiver Versandauftrag existiert bereits.
  • SHIPPING_ADDRESS_INVALID Die Lieferadresse ist unvollständig oder ungültig.
  • ORDER_NOT_READY_FOR_SHIPMENT Zahlung, Bestand oder Status erlaubt noch keinen Versand.

Fachliche Ereignisse

  • ShipmentPrepared

Verbindliche Szenarien

  • AC-FUL-001 Versandauftrag wird vorbereitet
  • AC-FUL-002 Versand vor Zahlung wird verhindert
  • AC-FUL-003 Doppelte Versandvorbereitung wird verhindert

UC-08 – Benachrichtigung senden

Primärakteur Notification Handler
Auslöser Ein fachlich relevantes Integration Event wurde empfangen.
Ergebnis Der Versandstatus ist nachvollziehbar gespeichert; Kerntransaktionen bleiben unabhängig.

Vorbedingungen

  • Für das Event ist eine Nachrichtenvorlage konfiguriert.
  • Der Empfänger besitzt einen zulässigen Kommunikationskanal.

Eingaben

  • EventId
  • Empfänger
  • Vorlagenkennung
  • fachliche Nachrichtendaten

Geschäftsregeln

  • BR-NOT-001 EventId und Kanal bilden einen idempotenten Versandauftrag.
  • BR-NOT-002 Ein Benachrichtigungsfehler rollt den abgeschlossenen Kernprozess nicht zurück.
  • BR-NOT-003 Personenbezogene Inhalte werden auf den notwendigen Umfang begrenzt.

Normalablauf

  1. Event und Empfänger prüfen.
  2. Idempotenz prüfen.
  3. Vorlage rendern.
  4. Nachricht über den Kanal senden.
  5. Versandstatus speichern.
  6. NotificationSent oder NotificationFailed veröffentlichen.

Fehlerfälle

  • NOTIFICATION_CHANNEL_UNAVAILABLE Der Kommunikationskanal ist technisch nicht erreichbar.
  • NOTIFICATION_RECIPIENT_INVALID Der Empfänger ist ungültig oder nicht freigegeben.
  • NOTIFICATION_TEMPLATE_MISSING Für den Ereignistyp fehlt eine Vorlage.

Fachliche Ereignisse

  • NotificationSent
  • NotificationFailed

Verbindliche Szenarien

  • AC-NOT-001 Bestellbestätigung wird versendet
  • AC-NOT-002 Kanalfehler beeinflusst Bestellung nicht
  • AC-NOT-003 Doppeltes Event sendet nicht doppelt

UC-09 – Bestellung stornieren

Primärakteur Kunde oder Customer Service
Auslöser Eine noch nicht versandte Bestellung soll beendet werden.
Ergebnis Die Bestellung ist storniert oder die Stornierung ist nachvollziehbar in Bearbeitung.

Vorbedingungen

  • Die Bestellung existiert.
  • Der Versand wurde noch nicht physisch gestartet.

Eingaben

  • OrderId
  • Stornierungsgrund
  • auslösender Akteur
  • IdempotencyKey

Geschäftsregeln

  • BR-CAN-001 Nach SHIPPED ist keine reguläre Stornierung mehr zulässig.
  • BR-CAN-002 Reservierter Bestand wird genau einmal freigegeben.
  • BR-CAN-003 Eine Autorisierung wird storniert oder rückabgewickelt, wenn sie bereits vorliegt.
  • BR-CAN-004 Wiederholte Stornierung ist idempotent.

Normalablauf

  1. Bestellung und Status prüfen.
  2. Stornierungsrecht prüfen.
  3. Status auf CANCELLATION_PENDING oder direkt CANCELLED setzen.
  4. Bestandsfreigabe anstoßen.
  5. Zahlungsstorno beziehungsweise Rückabwicklung anstoßen.
  6. OrderCancelled veröffentlichen, sobald notwendige Schritte bestätigt sind.

Fehlerfälle

  • ORDER_ALREADY_SHIPPED Die Bestellung wurde bereits versandt.
  • ORDER_NOT_FOUND Die Bestellung ist unbekannt.
  • CANCELLATION_CONFLICT IdempotencyKey wurde mit anderem Grund verwendet.

Fachliche Ereignisse

  • OrderCancellationRequested
  • InventoryReleased
  • PaymentVoided
  • OrderCancelled

Verbindliche Szenarien

  • AC-CAN-001 Unbezahlte Bestellung wird storniert
  • AC-CAN-002 Reservierter Bestand wird freigegeben
  • AC-CAN-003 Bezahlte Bestellung löst Zahlungsstorno aus
  • AC-CAN-004 Versandte Bestellung kann nicht regulär storniert werden

UC-10 – Zahlungsfehler behandeln

Primärakteur Payment Recovery Handler
Auslöser PaymentDeclined oder PaymentAuthorizationDeferred wurde empfangen.
Ergebnis Der Fehler ist eindeutig klassifiziert, wiederholt oder final abgeschlossen; Bestand und Status bleiben konsistent.

Vorbedingungen

  • Die Bestellung ist noch nicht versandt.
  • Der Fehler ist als fachlich oder technisch klassifiziert.

Eingaben

  • OrderId
  • PaymentId
  • Fehlerklasse
  • Provider-Code
  • Versuchsnummer

Geschäftsregeln

  • BR-ERR-001 Fachliche Ablehnungen werden nicht automatisch als technische Fehler wiederholt.
  • BR-ERR-002 Technische Fehler dürfen höchstens dreimal mit Backoff wiederholt werden.
  • BR-ERR-003 Nach endgültigem Fehlschlag wird reservierter Bestand freigegeben.
  • BR-ERR-004 Jeder Versuch ist mit CorrelationId und Attempt-Nummer nachvollziehbar.
  • BR-ERR-005 Eine verspätete erfolgreiche Antwort darf nicht zu doppelter Autorisierung führen.

Normalablauf

  1. Fehlerklasse und bisherigen Versuch prüfen.
  2. Bei technischer Störung nächsten Retry terminieren.
  3. Bei fachlicher Ablehnung Bestellung auf PAYMENT_FAILED setzen.
  4. Nach ausgeschöpften technischen Versuchen ebenfalls PAYMENT_FAILED setzen.
  5. Bestandsfreigabe anstoßen.
  6. PaymentFailedFinal veröffentlichen.

Fehlerfälle

  • PAYMENT_RETRY_EXHAUSTED Die zulässigen technischen Versuche sind ausgeschöpft.
  • PAYMENT_FAILURE_CLASS_UNKNOWN Der Fehler kann nicht sicher klassifiziert werden.
  • LATE_PAYMENT_RESULT_IGNORED Ein verspätetes Ergebnis trifft nach finaler Verarbeitung ein.

Fachliche Ereignisse

  • PaymentRetryScheduled
  • PaymentFailedFinal
  • InventoryReleaseRequested

Verbindliche Szenarien

  • AC-ERR-001 Fachliche Ablehnung wird final behandelt
  • AC-ERR-002 Erster technischer Fehler wird wiederholt
  • AC-ERR-003 Dritter technischer Fehler beendet Wiederholungen
  • AC-ERR-004 Finaler Zahlungsfehler gibt Bestand frei
  • AC-ERR-005 Verspätete Providerantwort erzeugt keine Doppelzahlung

Darstellung

Design
Text
Dichte
⌂ Cockpit