Structuration de projet efficace pour les microservices avec Quarkus

Dans le paysage en constante évolution du développement logiciel, l'adoption de l'architecture de microservices gagne rapidement du terrain en raison de son évolutivité, de sa flexibilité et de sa maintenabilité. Quarkus, en tant que pile Kubernetes Java native conçue pour GraalVM et HotSpot, optimise Java spécifiquement pour les conteneurs et lui permet de devenir une plate-forme efficace pour les environnements sans serveur, cloud et Kubernetes.

La clé pour tirer parti efficacement de Quarkus est de comprendre comment structurer correctement votre projet. Une bonne structuration du projet améliore non seulement la gérabilité du code, mais joue également un rôle crucial dans le succès du déploiement de l'architecture de microservices.

L'architecture des microservices se distingue par plusieurs caractéristiques déterminantes que Quarkus améliore :

1. Petit et ciblé : chaque service d'une architecture de microservices est conçu pour effectuer une tâche unique et bien définie, favorisant la simplicité et la concentration. Quarkus prend en charge cela en facilitant les fichiers jar légers et amorçables et les compilations natives, idéales pour des tâches spécifiques.

2. Indépendant : l'indépendance permet aux services d'être développés, déployés et même mis à l'échelle sans dépendre d'autres services. La philosophie de Quarkus axée sur les conteneurs garantit que chaque microservice peut s'exécuter dans son environnement isolé.

3. Lâchement couplés- les services communiquent via des API bien définies, réduisant ainsi la dépendance aux implémentations internes. Quarkus encourage le découplage via des normes telles que MicroProfile et JAX-RS, rendant l'interaction des services transparente et efficace.

4. Évolutif : il est crucial de gérer efficacement les charges de travail croissantes. Les capacités de programmation réactive de Quarkus permettent aux services d'être réactifs et évolutifs sous différentes charges.

5. Flexible- la capacité de s'adapter aux conditions changeantes est facilitée par les fonctionnalités de mise à l'échelle dynamique et de résilience de Quarkus, prenant en charge les ajustements à la volée dans un environnement cloud natif.

6. Résilient- Quarkus améliore la robustesse des microservices grâce à des capacités intégrées de tolérance aux pannes et de contrôle de l'état, garantissant que les services résistent aux pannes et se rétablissent rapidement après les interruptions.

L'adoption de structures de projet multi-modules Maven s'est avérée efficace pour gérer des applications Java à grande échelle, et Quarkus prend entièrement en charge cette modalité. Détaillons la structure multi-module Maven :

Un projet multi-module Maven est constitué d'un agrégateur POM qui orchestre plusieurs sous-modules. Cette structure est avantageuse pour diviser une application volumineuse en unités gérables et déployables indépendamment qui peuvent être facilement entretenues et mises à jour. Chaque module a généralement une responsabilité ciblée et peut être déployé indépendamment des autres.

Voici une mise en page simplifiée basée sur une application réelle :

parent (aggregator pom.xml)
├── api (API interfaces and DTOs)
│   ├── pom.xml
│   └── src
├── core (Business logic)
│   ├── pom.xml
│   └── src
├── data-access (Data layer integration)
│   ├── pom.xml
│   └── src

J'ai conçu une structure de projet optimisée spécifiquement pour Quarkus qui améliore l'évolutivité, la maintenabilité et la cohérence entre diverses équipes de développement. Le design, que j’ai initialement développé en 2018, a connu plusieurs améliorations pour mieux s’adapter à l’évolution des tendances technologiques. Au départ, la structure n'était pas spécifiquement conçue pour Quarkus ; cependant, tout au long de son application, il s'est avéré exceptionnellement compatible avec la philosophie et les pratiques de codage de Quarkus. Examinons cette structure telle qu'implémentée dans un IDE comme IntelliJ IDEA - bien qu'elle puisse être efficacement adaptée à tout autre IDE moderne.

Vous pouvez trouver la structure complète du projet dans le référentiel GitHub

En partant du niveau supérieur, le projet est divisé en plusieurs modules, chacun avec un rôle spécifique :

1. api-dtos- ce module est crucial pour découpler les représentations internes des données de ce qui est exposé en externe via les API. En séparant les objets de transfert de données (DTO) des modèles de domaine, le module garantit que toute modification, qu'elle soit apportée au schéma de base de données ou à la logique métier, n'affecte pas directement les clients qui consomment ces API. Cette séparation améliore la stabilité et la gestion des versions de l'API.

2. commons- ce module utilitaire agit comme un référentiel pour la logique partagée, les constantes et les assistants qui sont utilisés dans plusieurs autres modules du projet. Cette centralisation des fonctionnalités communes réduit la duplication et favorise la cohérence dans l’ensemble de l’application. Il est particulièrement utile pour stocker des utilitaires tels que des convertisseurs de format de données, des validateurs standard ou des règles métier courantes.

3. configuration- la gestion de la configuration est rationalisée dans ce module, qui consolide tous les paramètres de configuration pour l'ensemble de l'application en un seul endroit, simplifiant l'accès et la gestion. Ce référentiel central de configurations garantit que les paramètres sont appliqués et gérés de manière cohérente, simplifiant les changements d'environnement (par exemple du développement à la production) et minimisant le risque d'erreurs dues à une mauvaise configuration. Au-delà des simples fichiers de configuration, ce module est également l'emplacement idéal pour définir des beans gérés personnalisés qui sont essentiels dans l'application, tels que ObjectMapper pour la sérialisation et la désérialisation JSON, les désérialiseurs personnalisés et d'autres beans spécialisés.

4. db-entities- dédié exclusivement aux interactions de bases de données, ce module encapsule toutes les classes ORM ou schémas de base de données, garantissant qu'ils sont séparés de la logique métier et des couches API. La séparation des entités de cette manière permet de maintenir des principes d'architecture propres en dissociant les mécanismes d'accès aux données du traitement des règles métier, favorisant ainsi une base de code plus propre et plus traçable.

5. services- voici la logique métier de base, encapsulée dans des classes de services qui fonctionnent sur des modèles de domaine et utilisent des entités de base de données pour la persistance des données. Chaque service se concentre sur une tâche métier spécifique, améliorant ainsi la modularité et la réutilisabilité. Cette séparation permet également d'isoler les opérations commerciales des interactions directes avec les clients, qui sont gérées par les classes de contrôleurs dans d'autres modules, adhérant ainsi au principe de responsabilité unique.

6. ressources- au milieu de débats, ce module a été nommé pour refléter son alignement avec JAX-RS, où les classes annotées avec JAX-RS sont appelées ressources. Ce module gère la création de points de terminaison REST, agissant comme la couche de communication qui s'interface avec les clients externes. Le nom « ressources » a été choisi plutôt que des alternatives telles que « repos » ou « contrôleurs » pour mettre l'accent sur la standardisation et le respect des principes RESTful établis, tels que décrits dans la ressource Red Hat pour la création d'API REST avec Quarkus. En s'alignant sur la terminologie standard, le projet vise à être intuitif pour les développeurs familiarisés avec les conventions JAX-RS et REST.

7. application- sert de module parapluie qui rassemble toutes les pièces, garantissant qu'elles sont correctement câblées et prêtes à être déployées.

Chacun de ces modules joue un rôle stratégique adapté pour favoriser la facilité de maintenance, l'évolutivité et la robustesse dans un environnement de microservices Cloud-Native utilisant Quarkus.

La structure ci-dessus est basée sur les couches d'architecture suivantes mentionnées dans les ressources RedHat

---

Beaucoup d’abstraction, c’est trop

Lorsque l'on discute des structures de projet, une question courante se pose concernant la nécessité de l'approche à plusieurs niveaux que j'ai décrite précédemment. Ici, j'évoque les mots de David J. Wheeler :

Tous les problèmes en informatique peuvent être résolus par un autre niveau d'indirection, à l'exception du problème du trop grand nombre de couches d'indirection. - [David J. Wheeler de The C++ Programming Language 4e édition.]

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!