Quarkus & MicroProfile Umsetzung im Praxisprojekt
Quarkus und MicroProfile verbinden Enterprise Java APIs mit cloud-nativer Laufzeit, schnellen Starts und Kubernetes-Nähe.
QuarkusMicroProfileCloud NativeNative Image
In dieser Datei
Rolle
Quarkus eignet sich, wenn schnelle Startup-Zeiten, Container, Kubernetes/OpenShift, geringe Speicherlast und MicroProfile-nahe APIs wichtig sind. Die Domain bleibt auch hier unabhängig.
Resource
Quarkus/JAX-RS Adapter
@Path("/orders")
@Consumes(MediaType.APPLICATION_JSON)
@Produces(MediaType.APPLICATION_JSON)
public class QuarkusOrderResource { // Pattern: Inbound Adapter
private final PlaceOrderUseCase placeOrder;
public QuarkusOrderResource(PlaceOrderUseCase placeOrder) {
this.placeOrder = placeOrder;
}
@POST
public Response place(PlaceOrderRequest request) {
OrderId id = placeOrder.handle(request.toCommand());
return Response.accepted(new OrderResponse(id.value(), "ACCEPTED")).build();
}
}
Fault Tolerance
MicroProfile Fault Tolerance am technischen Adapter
@ApplicationScoped
class InventoryClient implements InventoryPort { // Pattern: Adapter
@Timeout(750)
@Retry(maxRetries = 2)
@CircuitBreaker(requestVolumeThreshold = 20, failureRatio = 0.5)
public void reserve(CustomerId customerId, List<OrderLine> lines) {
// HTTP call zum Inventory-System
}
}
Config
MicroProfile Config erlaubt saubere externe Konfiguration. Keine Secrets im Code, keine Umgebungsspezifika in der Domain.
Health
Liveness prüft, ob der Prozess lebt. Readiness prüft, ob Traffic angenommen werden darf. Startup prüft lange Initialisierungen.
Trade-offs
| Vorteil | Risiko |
|---|---|
| Schneller Start und geringer Footprint | Build-/Native-Komplexität beachten |
| Kubernetes-nahe Erweiterungen | Framework-spezifische Extension-Welt |
| MicroProfile Standards | Nicht jede API deckt jedes Enterprise-Szenario ab |