Start / Micronaut

Micronaut

Compile-Time DI, schlanke Microservices und testbare modulare Anwendungen.

Enterprise JavaBeispieleArchitekturOffline HTML
In dieser Datei
  1. Micronaut im Vergleich
  2. Wann Micronaut sinnvoll ist
  3. Client- und Konfigurationsdisziplin

Micronaut im Vergleich

Micronaut setzt stark auf Compile-Time Dependency Injection und vermeidet dadurch viel Runtime-Reflection. Das kann für Microservices, Serverless und schnelle Starts interessant sein. Für Teams ist vor allem wichtig, dass die Architektur nicht allein aus Framework-Magie besteht: Controller bleiben Adapter, Use Cases bleiben fachlich, Clients erhalten klare Timeout- und Fehlerregeln.

Micronaut Controller
@Controller("/orders")
class OrderController {
    private final PlaceOrderUseCase placeOrder;

    OrderController(PlaceOrderUseCase placeOrder) {
        this.placeOrder = placeOrder;
    }

    @Post
    HttpResponse<OrderResponse> create(@Body @Valid PlaceOrderRequest request) {
        OrderId id = placeOrder.handle(request.toCommand());
        return HttpResponse.created(new OrderResponse(id.value()));
    }
}

Wann Micronaut sinnvoll ist

SzenarioWarum passendWorauf achten
Neue MicroservicesLeichtgewichtig, schnelle Starts, testbarTeam-Know-how und Ökosystem prüfen
ServerlessStartup und Speicher relevantCold Start ist nur ein Teil der Architektur
Modulare JVM-AnwendungCompile-Time DI macht Abhängigkeiten sichtbarFramework-spezifische Annotationen nicht in Domain ziehen
Migration von SpringKonzepte ähnlich, Details andersAuto-Configuration nicht 1:1 erwarten

Client- und Konfigurationsdisziplin

In jedem Microservice-Framework gilt: Externe Clients brauchen Timeouts, Retry-Strategien, Fehler-Mapping und Observability. Ohne diese Regeln wird ein einzelner Partnerausfall schnell zur Kaskade im ganzen System.

⌂ Cockpit