Dans le développement logiciel, on cherche souvent à résoudre les problèmes d'évolutivité, de maintenabilité et de testabilité du code. C’est là qu’entre en scène l'Architecture Hexagonale, aussi appelée "Ports and Adapters".
L'idée de cette approche développée par Alistair Cockburn est que le domaine métier (le cœur de ton application) soit isolé du reste du système et puisse être utilisé indépendamment des technologies externes (framework, base de données, UI, API externes).
Allez, on va plonger dans les concepts fondamentaux de l'Architecture Hexagonale et voir ensemble comment elle peut transformer la manière dont tu conçois ton code ! 😉
C'est quoi exactement l'Architecture Hexagonale ?
L'Architecture Hexagonale est une façon de structurer une application pour qu’elle soit indépendante des détails externes. Elle insiste sur la séparation des préoccupations en découpant l'application en plusieurs couches distinctes.
Le but est de rendre l'application indépendante des technologies spécifiques, en organisant les interactions entre le cœur de l'application (la logique métier) et le monde extérieur (base de données, interfaces utilisateur, API, frameworks, etc.), tout ça via des Ports et des Adapters.
Le concept de base
Imagine ton application comme un hexagone avec, au centre, le domain (la logique métier). Ce cœur métier ne doit pas être directement lié aux détails d'implémentation (comme Symfony, Doctrine, une API tierce, etc.). Pour y arriver, il va falloir créer des interfaces appelées Ports, et ces interfaces vont être implémentées par des Adapters, qui s'occupent de la communication avec les services externes.
🛂 Ports : autrement dit, les interfaces par lesquelles le monde extérieur peut interagir avec le noyau métier. Les ports, ce sont les points d’entrée ou de sortie de l’application (API, requêtes HTTP, commandes CLI, etc.).
🎯 Adapters : les adapters sont les implémentations concrètes de ces interfaces. Ils traduisent les demandes ou réponses externes en actions compréhensibles pour la logique métier. Cela inclut les interactions avec les bases de données, les frameworks, les API, etc.
Structure d'une application hexagonale
Pour mieux comprendre, on va se baser sur un exemple simple en Symfony. Imaginons que ton application doit permettre à des utilisateurs de passer des commandes, et qu'elle doit interagir avec une base de données pour stocker ces commandes.
Eh bien, regarde comment tu pourrais structurer ton application selon l'architecture hexagonale. 👀
1. Le Cœur Métier
C’est le noyau de ton application, la partie qui n'a aucune dépendance externe. C’est là que réside la logique métier, comme la création d’une commande, la validation de ses données, etc.
Ici, la classe Order représente le modèle de base d'une commande. Tu remarqueras que cette classe ne sait rien de la manière dont elle sera stockée, ni d’où viennent les données.
2. Les Ports (Interfaces)
Les Ports définissent les interfaces que les adaptateurs vont devoir implémenter pour que la logique métier puisse fonctionner. Ils peuvent être des points d'entrée dans le système (comme des requêtes HTTP) ou des points de sortie (comme les appels à la base de données).
L'interface OrderRepositoryInterface va servir de port de sortie. Elle ne fait que définir les méthodes dont la logique métier a besoin pour interagir avec la base de données. Le domaine ne sait pas comment ces données vont être sauvegardées.
3. Les Adapters (Implémentations)
L'Adapter, c'est tout simplement l'implémentation concrète d'un Port. L'Adapter va permettre de traduire :
- toutes les interactions externes vers la logique métier
- la logique métier vers des actions concrètes (comme sauvegarder dans une base de données).
L’adapter ici traduit l’appel à OrderRepositoryInterface en une interaction avec Doctrine (bibliothèque de gestion de base de données) mais ta logique métier n'a aucune idée que Doctrine est utilisé.
4. Un exemple de contrôleur dans Symfony
Le contrôleur va agir comme un point d’entrée pour notre application. C’est lui qui interagit avec l’utilisateur via les requêtes HTTP, puis délègue les tâches au domaine via les Ports et Adapters.
Ici, tu peux voir que le contrôleur ne connaît que l’interface OrderRepositoryInterface et pas l’implémentation concrète. Ca permet de rendre le code testable, extensible, et indépendant des frameworks et technologies externes (Symfony, Doctrine, etc.).
Pourquoi utiliser l'Architecture Hexagonale ?
En séparant ta logique métier des implémentations externes (base de données, HTTP, API externes), tu rends ton code plus flexible. Changer de base de données ou de framework devient plus simple et moins risqué.
Comme la logique métier n'est pas liée à des éléments externes, tu peux facilement mock ou remplacer les adaptateurs dans tes tests.
Avec cette séparation claire, il est plus facile d'ajouter de nouvelles fonctionnalités, de modifier des comportements ou de réutiliser certains composants sans toucher à la logique métier.
Tu peux réutiliser le même cœur métier avec différents types d'adaptateurs. Par exemple, la même logique métier peut être utilisée pour une application web, une API REST ou encore une interface en ligne de commande.
Mais attention !
Même si l'architecture hexagonale est puissante, structurer ton application de cette façon peut être un peu overkill, surtout pour des petits projets. Pour des petites applications, l'architecture hexagonale peut ajouter une complexité inutile, car tout découpler n’est pas toujours nécessaire.
Top comments (0)