Komplexes Enterprise-Beispiel: Order & Billing Jakarta Blueprint

Das Beispiel verbindet REST, CDI, Validation, Persistence, Transactions, Messaging und Batch in einer realistischen Order-&-Billing-Landschaft.

Fachliches Verständnis

Es zeigt, wie Jakarta-Spezifikationen zusammenwirken und wo klare Schichten liegen: Adapter, Application Service, Domain, Persistence und Integration. In der Praxis ist wichtig, die Spezifikation nicht mit der konkreten Runtime zu verwechseln. Der Standard beschreibt die portablen APIs, die Implementierung entscheidet über Konfiguration, Performance, Betrieb und Support.

Technisches Beispiel

@Path("/orders")
@RequestScoped
public class OrderResource {
    @Inject PlaceOrderUseCase useCase;
    @POST public Response place(@Valid PlaceOrderRequest request) {
        OrderId id = useCase.place(request.toCommand());
        return Response.accepted(new OrderAccepted(id.value())).build();
    }
}

@ApplicationScoped
public class PlaceOrderUseCase {
    @Inject OrderRepository repository;
    @Inject OrderEventPublisher publisher;

    @Transactional // Unit of Work Pattern: Use Case ist Konsistenzgrenze.
    public OrderId place(PlaceOrderCommand command) {
        Order order = Order.place(command); // Factory Method Pattern im Domainmodell.
        repository.save(order);             // Repository Pattern.
        publisher.publish(new OrderPlaced(order.id())); // Observer/Event Pattern.
        return order.id();
    }
}

Enterprise-Fallen

• Alle Jakarta APIs in eine Klasse packen.
• Keine Ports/Adapter-Trennung.
• Events ohne Outbox/Idempotenz.

Legacy-Modernisierung

Der Blueprint ist bewusst als Modularisierungsvorlage gedacht: zuerst im Modulith, später optional als Services trennen.