Structuration d'une API Quarkus avec séparation Resource-Service-Repository

Scénario

Contexte : Votre application Quarkus a été développée rapidement et la logique métier est actuellement placée directement dans les classes Resource. Le Problème : Le code devient difficile à maintenir et à tester à mesure que le projet évolue. Contraintes : Mettre en place une séparation claire entre couche REST (Resource), services métier (@ApplicationScoped) et accès base via Panache ou repository dédié. Livrable attendu : Refactoriser l'application afin d'isoler la logique métier dans un service injectable et centraliser l'accès aux données dans une couche repository propre.

Compétences ciblées