L’architecture hexagonale avec Spring Boot est une méthode de conception qui aide à structurer les applications de manière à découpler la logique métier des détails d’infrastructure. Ce modèle est particulièrement pertinent pour les applications développées avec Spring Boot, offrant ainsi flexibilité, testabilité et maintenabilité.
L’architecture hexagonale repose sur l’idée que la logique métier doit être indépendante des interfaces utilisateur, des bases de données ou des API externes. Cette séparation garantit une meilleure évolutivité et permet d’adapter facilement l’application à de nouvelles technologies sans impacter la logique métier. Par exemple, on peut changer une base de données MongoDB pour Cassandra ou PostgreSQL sans modifier le noyau de l’application. Vous pouvez en savoir plus sur les bonnes pratiques et les implémentations de microservices avec Docker et Kubernetes, ce qui complète souvent l’architecture hexagonale dans les environnements modernes.
Concepts clés de l’architecture hexagonale
Structure : L’intérieur vs. L’extérieur
Dans le modèle d’architecture hexagonale, le système est divisé en deux parties distinctes :
- L’intérieur, qui correspond à la logique métier.
- L’extérieur, qui correspond aux interfaces avec les systèmes externes comme les bases de données, les services API, ou les utilisateurs.
Ces deux parties sont connectées via des ports (interfaces) et des adaptateurs (implémentations). Les ports représentent les interfaces qui exposent la logique métier aux systèmes externes, tandis que les adaptateurs implémentent ces interfaces pour communiquer avec l’infrastructure ou les API. Cette approche permet de maintenir une stricte indépendance entre la logique métier et les technologies utilisées.
Consultez cet article sur les bonnes pratiques pour développer des API Spring Boot, qui illustre comment intégrer des API robustes dans une architecture hexagonale.
La couche Application
La couche application est responsable de l’interaction avec les utilisateurs ou les systèmes externes. Dans une application Spring Boot, cela inclut généralement les contrôleurs REST, qui permettent à des clients externes (navigateurs, applications mobiles) d’interagir avec l’application via des API HTTP.
Les principaux composants de cette couche sont :
- Contrôleurs REST : Ils permettent d’exposer des points d’entrée HTTP que les utilisateurs ou autres systèmes peuvent appeler pour interagir avec la logique métier.
- Sérialisation JSON : Conversion des objets Java en JSON et vice versa, facilitant la communication avec l’extérieur.
En architecture hexagonale, ces contrôleurs agissent comme des adaptateurs qui permettent aux utilisateurs ou systèmes externes d’interagir avec la logique métier sans y avoir un accès direct.
La couche Domaine
La couche Domaine est au cœur de l’application. Elle contient toutes les règles et la logique métier. Elle est complètement découplée des autres couches comme la base de données ou l’interface utilisateur. Cela permet d’assurer que la logique métier reste indépendante des changements technologiques et peut être réutilisée facilement dans différents contextes.
- Entités de domaine : Elles représentent les objets métiers qui sont manipulés par l’application.
- Services de domaine : Ils encapsulent les règles métiers complexes et orchestrent le comportement des entités.
Un avantage majeur de cette approche est que la logique métier peut être testée indépendamment des autres couches, garantissant ainsi une grande testabilité de l’application.
La couche Infrastructure
La couche Infrastructure contient tout ce qui est nécessaire pour que l’application fonctionne techniquement. Cela inclut les bases de données, les systèmes de messagerie, les API externes, et la configuration des frameworks comme Spring Boot.
Les composants principaux de cette couche sont :
- Dépôts de données : Ils permettent de persister et récupérer les objets métiers via des systèmes de stockage comme les bases de données.
- Configuration Spring : Les fichiers de configuration qui initialisent les beans et autres composants techniques.
L’architecture hexagonale permet d’ajouter ou de modifier facilement ces composants sans impacter la logique métier. Cela signifie que si vous changez de base de données (de MongoDB à PostgreSQL, par exemple), vous n’aurez pas à modifier la logique métier, seulement l’adaptateur qui interagit avec la nouvelle base de données.
Implémentation de l’architecture hexagonale avec Spring Boot
Étapes pour implémenter l’architecture hexagonale
1. Créer les classes de domaine
La couche domaine est le centre de l’architecture hexagonale. Elle doit rester indépendante de l’infrastructure et des technologies externes. Voici un exemple de classe Order
pour un système de gestion des commandes :
public class Order { private UUID id; private OrderStatus status; private List<OrderItem> orderItems; private BigDecimal price; public Order(UUID id, Product product) { this.id = id; this.orderItems = new ArrayList<>(Arrays.asList(new OrderItem(product))); this.status = OrderStatus.CREATED; this.price = product.getPrice(); } public void complete() { validateState(); this.status = OrderStatus.COMPLETED; } // Autres méthodes ... }
Dans cette classe, la commande (Order
) maintient sa propre cohérence et encapsule la logique de gestion des états et des articles de la commande.
2. Créer des ports et adaptateurs
Les ports et adaptateurs sont les éléments qui permettent de connecter la logique métier à l’extérieur. Par exemple, une interface OrderRepository
peut être définie comme un port pour la persistance des données :
public interface OrderRepository { Optional<Order> findById(UUID id); void save(Order order); }
Les adaptateurs implémentent cette interface en utilisant une base de données, une API externe ou tout autre système de stockage.
3. Implémenter la couche Application
La couche application est souvent représentée par des contrôleurs REST dans les applications Spring Boot. Ces contrôleurs permettent d’exposer des API aux utilisateurs et aux autres systèmes externes. Voici un exemple de contrôleur REST OrderController
:
@RestController @RequestMapping("/orders") public class OrderController { private final OrderService orderService; @Autowired public OrderController(OrderService orderService) { this.orderService = orderService; } @PostMapping public CreateOrderResponse createOrder(@RequestBody CreateOrderRequest request) { UUID id = orderService.createOrder(request.getProduct()); return new CreateOrderResponse(id); } // Autres méthodes ... }
Tests avec l’architecture hexagonale
L’architecture hexagonale permet de tester la logique métier indépendamment de l’infrastructure. Voici un exemple de test unitaire pour la classe DomainOrderService
:
class DomainOrderServiceUnitTest { private OrderRepository orderRepository; private DomainOrderService tested; @BeforeEach void setUp() { orderRepository = mock(OrderRepository.class); tested = new DomainOrderService(orderRepository); } @Test void shouldCreateOrder_thenSaveIt() { Product product = new Product(UUID.randomUUID(), BigDecimal.TEN, "productName"); UUID id = tested.createOrder(product); verify(orderRepository).save(any(Order.class)); assertNotNull(id); } }
Ce test montre comment nous pouvons valider la logique métier sans avoir besoin de bases de données ou d’autres services externes.
Avantages de l’architecture hexagonale avec Spring Boot
Séparation des préoccupations
L’architecture hexagonale permet une séparation claire entre la logique métier et l’infrastructure, ce qui facilite la maintenance de l’application. Chaque couche peut évoluer indépendamment, sans risque de casser d’autres fonctionnalités.
Testabilité et évolutivité
La testabilité est l’un des principaux avantages de cette approche. Grâce à la séparation entre la logique métier et les autres couches, il est possible d’écrire des tests unitaires isolés. De plus, cette architecture facilite l’ajout de nouvelles fonctionnalités ou la migration vers de nouvelles technologies.
Flexibilité
L’architecture hexagonale rend l’application plus flexible. Par exemple, si vous souhaitez passer d’une API REST à une application CLI ou modifier la base de données sous-jacente, vous pouvez le faire sans toucher à la logique métier.
Défis et meilleures pratiques
Défis
Bien que l’architecture hexagonale présente de nombreux avantages, elle peut être complexe à mettre en œuvre, en particulier pour les petites équipes ou les applications de petite taille. Elle peut également nécessiter un effort de refactorisation pour séparer correctement les préoccupations.
Meilleures pratiques
- Organiser les paquets : Il est recommandé d’organiser les classes en fonction de leur rôle dans l’architecture (domaine, application, infrastructure).
- Limiter les dépendances : Assurez-vous que la couche domaine ne dépend d’aucune technologie spécifique à l’infrastructure.
FAQ
Qu’est-ce que l’architecture hexagonale et pourquoi est-elle importante pour les applications Spring Boot ?
L’architecture hexagonale est une méthode de conception qui permet de séparer la logique métier des détails d’infrastructure, garantissant une plus grande flexibilité et testabilité.
Comment l’architecture hexagonale se distingue-t-elle de l’architecture en couches traditionnelle ?
Contrairement à l’architecture en couches, qui introduit souvent des dépendances entre les différentes couches, l’architecture hexagonale isole complètement la logique métier des technologies externes, facilitant ainsi les changements et les évolutions.
Comment implémenter des ports et des adaptateurs dans un projet Spring Boot ?
Les ports sont des interfaces qui exposent la logique métier aux systèmes externes. Les adaptateurs implémentent ces interfaces pour communiquer avec l’infrastructure.
Conclusion
L’architecture hexagonale est un modèle de conception qui favorise la modularité, la testabilité et la flexibilité dans le développement d’applications Spring Boot. En séparant clairement la logique métier des autres préoccupations, cette architecture permet de créer des systèmes plus robustes et évolutifs, capables de s’adapter à de nouvelles exigences technologiques sans compromettre la structure fondamentale de l’application.
1 Comment
Pingback: Clean Architecture vs Hexagonale : Comment choisir ? - CodinGoal