Architecture hexagonale : isoler le métier de l’infrastructure
Le choix de l’architecture de votre application se fait généralement en début de projet, lors de la phase de conception. L’architecture hexagonale (ou Ports and Adapters) propose une séparation claire entre le code métier et le code technique. Chez Eve Media, nous utilisons cette architecture pour les applications complexes.
Le problème des architectures traditionnelles
Dans une architecture classique en couches, le code métier dépend souvent directement de la base de données, du framework, des APIs externes. Changer de base de données ou de framework devient un projet majeur. Les tests nécessitent l’infrastructure complète.
Le principe de l’hexagone
Au centre : le domaine métier, pur, sans dépendance externe. Autour : des ports (interfaces) qui définissent comment le domaine communique avec l’extérieur. À l’extérieur : des adapters qui implémentent ces ports pour des technologies spécifiques.
Ports entrants (driving)
Les ports entrants définissent ce que l’application peut faire. Ce sont les use cases, les services applicatifs. Un controller HTTP, une CLI, un consumer de messages appellent ces ports. Ils drivvent l’application.
Ports sortants (driven)
Les ports sortants définissent ce dont l’application a besoin : persister des données, envoyer des emails, appeler une API. Le domaine définit l’interface (ex: UserRepository), l’adapter implémente pour PostgreSQL ou MongoDB.
Inversion de dépendance
La clé : le domaine ne dépend de rien, tout dépend du domaine. Le domaine définit les interfaces, l’infrastructure les implémente. C’est le principe d’inversion de dépendance (DIP) de SOLID.
Testabilité
Le domaine peut être testé sans base de données, sans HTTP, sans rien d’externe. Injectez des mocks ou des in-memory adapters. Les tests sont rapides, fiables, focalisés sur la logique métier.
Changement de technologie
Changer de base de données ? Écrivez un nouvel adapter, le domaine ne change pas. Passer de REST à GraphQL ? Nouvel adapter entrant, le domaine ne change pas. La flexibilité technologique est maximale.
Structure de projet
Organisation typique : /domain (entités, value objects, services domaine, ports), /application (use cases, orchestration), /infrastructure (adapters : database, http, messaging). La frontière entre les couches est explicite.
Quand utiliser l’architecture hexagonale
Pour les applications avec une logique métier complexe. Quand la testabilité est critique. Quand la longévité de l’application dépasse celle des frameworks. Pour les équipes qui veulent une séparation claire des responsabilités.
Quand ne pas l’utiliser
Pour un simple CRUD sans logique métier. Pour des prototypes ou MVPs jetables. Quand l’équipe n’est pas familière et le temps manque pour la formation. L’overhead n’est pas toujours justifié.
Conclusion
L’architecture hexagonale demande un investissement initial mais paie sur la durée. Les applications sont plus testables, plus flexibles, plus maintenables. C’est un pattern éprouvé pour les projets ambitieux.
Chez Eve Media, nous concevons des architectures adaptées à vos enjeux. Contactez-nous pour des applications robustes.