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.
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 V4 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
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.