Order-to-Cash End-to-End Case Study

End-to-end Ablauf vom Portal bis Buchhaltung, inklusive fachlicher Zuständigkeiten, Schnittstellen, Fehlerfällen und Betriebsnachweisen.

Case StudyOrder-to-CashE2ESenior
Order-to-Cash End-to-End Case Study
Order-to-Cash End-to-End Case Study

Fachlicher Ablauf

Order-to-Cash beginnt nicht im Controller, sondern bei einer fachlichen Absicht: Ein Kunde will etwas bestellen. Danach folgen Preisprüfung, Limitprüfung, Bestandsreservierung, Rechnungslogik, Event-Publish und Betriebsnachweis. In Enterprise-Projekten ist wichtig, jeden Schritt einem System Owner und einer Transaktionsgrenze zuzuordnen.

Technischer Schnitt

Der rote Faden in V5 ist ein Vertikalschnitt. Jede Schicht bekommt nur die Verantwortung, die sie tragen kann: Portal/BFF für Darstellung, Application Service für Use Case, Domain für Invarianten, Adapter für Fremdsysteme, Outbox für technische Übergabe.

Beispielcode

Application Service mit Ports und Idempotenz
package at.aydinsude.enterprise.order.application;

import at.aydinsude.enterprise.order.domain.*;
import java.time.Clock;

// Pattern: Application Service - orchestriert genau einen fachlichen Use Case.
// Pattern: Port-and-Adapter - nutzt RepositoryPort und EventPublisherPort statt Framework-Abhängigkeiten.
public final class PlaceOrderUseCase {
    private final OrderRepositoryPort orders;
    private final CustomerRiskPort customerRisk;
    private final EventPublisherPort events;
    private final Clock clock;

    public PlaceOrderUseCase(OrderRepositoryPort orders,
                             CustomerRiskPort customerRisk,
                             EventPublisherPort events,
                             Clock clock) {
        this.orders = orders;
        this.customerRisk = customerRisk;
        this.events = events;
        this.clock = clock;
    }

    public OrderId handle(PlaceOrderCommand command) {
        if (orders.existsByIdempotencyKey(command.idempotencyKey())) {
            return orders.findOrderIdByIdempotencyKey(command.idempotencyKey());
        }
        customerRisk.assertCustomerMayOrder(command.customerId(), command.total());
        Order order = Order.place(command.customerId(), command.lines(), command.idempotencyKey(), clock.instant());
        orders.save(order);
        events.publishAll(order.pullDomainEvents());
        return order.id();
    }
}

Praxisübertragung auf das V4-Beispielprojekt

Entscheidung

Dokumentiere die getroffene Architekturentscheidung als ADR, inklusive Alternativen, Folgen und Betriebsrisiken.

Code-Nachweis

Markiere verwendete Entwurfsmuster direkt im Code und ergänze sie in docs/design-patterns.md.

Betrieb

Definiere Metrik, Alert, Runbook-Schritt und Rollback-Option für diesen Bereich.

Typische Fehlerbilder

  • Framework-Feature wird eingesetzt, ohne fachliche Grenze zu verstehen.
  • Technische Wiederholung wird nicht idempotent gemacht.
  • Observability wird erst nach Produktionsproblem ergänzt.
  • Tests prüfen nur Happy Path und keine Wiederanläufe.
⌂ Cockpit