07 - Quand utiliser (et ne pas utiliser) l'hexa
Ce que tu vas apprendre
- Les situations ou l'architecture hexagonale apporte un vrai gain
- Les cas ou c'est overkill (et ce qu'il faut faire a la place)
- Comment l'hexa se compare a clean architecture, MVC et les vertical slices
Prerequisites
Utilise l'hexa quand...
Ta logique métier est complexe. Si ton application calcule des prix avec des remises conditionnelles, gere des workflows a plusieurs étapes, applique des regles de validation qui dependent du contexte... l'hexa protégé cette logique des détails techniques. Un CRUD basique n'a pas besoin de ca. Un système de reservation avec annulations partielles, remboursements et listes d'attente, oui.
Tu as plusieurs points d'entree. Une API REST, une CLI d'administration, un job cron qui traite des commandes en attente, un webhook Stripe. Si ta logique métier est accessible depuis plusieurs canaux, les ports entrants evitent de dupliquer le code. J'ai vu des projets ou la meme logique etait copiee-collee dans 3 controllers différents. Avec l'hexa, un seul use case, plusieurs adaptateurs entrants.
Tu prevois des changements d'infrastructure. Migration de base de donnees, changement de provider de paiement, passage de REST a GraphQL. Si c'est probable dans les 12 prochains mois, l'hexa rend ces changements quasi-indolores. Sans, chaque migration est un projet en soi.
Ton équipe a plus de 2 développeurs. L'hexa force des frontieres claires entre les couches. Un développeur fullstack peut travailler sur le domaine pendant qu'un autre code un adaptateur, sans conflit. Les interfaces servent de contrat entre les développeurs, pas seulement entre les couches.
Le projet va durer plus de 6 mois. La dette technique s'accumule vite sur un projet couple au framework. L'hexa est un investissement initial qui rapporte sur la duree. Si ton projet est un one-shot de 3 semaines, cet investissement ne sera pas rentabilise.
N'utilise PAS l'hexa quand...
C'est un CRUD sans logique métier. Si ton application fait Create-Read-Update-Delete sur 5 tables sans aucune regle métier, l'hexa ajoute des couches inutiles. Un controller qui appelle Prisma directement, c'est tres bien pour ca. Ne complexifie pas un problème simple.
C'est un prototype ou un MVP. Tu cherches a valider une idee le plus vite possible. La vitesse de livraison prime sur la qualité architecturale. Code vite, couple tout, et refactore plus tard si l'idee fonctionne. Je le pense sincerement : un prototype proprement architecture est un prototype livré trop tard.
Tu es seul avec 3 endpoints. Solo, tu connais tout le code. Les frontieres nettes entre couches te ralentissent sans benefice. Quand le projet grossit ou que l'équipe s'agrandit, tu pourras toujours migrer vers l'hexa incrementalement.
Ton équipe ne connaît pas le pattern. Imposer l'hexa a une équipe qui n'en a jamais fait, sans formation ni accompagnement, c'est la garantie d'un code "hexa en façade" avec des raccourcis partout. Forme d'abord, applique ensuite.
Comparaison avec les autres approches
| Critère | Hexa (Ports & Adapters) | Clean Architecture | MVC classique | Vertical Slices |
|---|---|---|---|---|
| Createur | Alistair Cockburn | Robert C. Martin | Trygve Reenskaug | Jimmy Bogard |
| Complexite de setup | Moyenne | Haute | Basse | Moyenne |
| Nombre de couches | 3 (domaine, ports, adapters) | 4+ (entities, use cases, interfaces, frameworks) | 3 (model, view, controller) | 1 par feature |
| Testabilite du domaine | Excellente | Excellente | Variable | Bonne |
| Permutabilite infra | Excellente | Excellente | Faible | Moyenne |
| Courbe d'apprentissage | Moderee | Raide | Faible | Moderee |
| Adapte pour CRUD | Non | Non | Oui | Oui |
| Adapte pour logique complexe | Oui | Oui | Limite | Oui |
Hexa vs Clean Architecture
La clean architecture d'Uncle Bob est tres proche de l'hexa. Les deux partagent la meme idee : le domaine au centre, les dépendances qui pointent vers l'intérieur. La différence principale est le nombre de couches. La clean architecture en impose 4 minimum (entities, use cases, interface adapters, frameworks & drivers). L'hexa est plus flexible : 3 zones, pas de convention rigide sur le découpage interne.
Mon avis : pour la plupart des projets backend TypeScript, l'hexa est suffisante. La clean architecture apporte une granularité supplementaire qui se justifie sur des systèmes tres larges (50+ use cases).
Hexa vs MVC
Le MVC ne dit rien sur la séparation entre logique métier et infrastructure. Ton model peut appeler directement la base, ton controller peut contenir des regles métier. C'est un pattern d'organisation de code, pas un pattern d'architecture.
L'hexa est plus strict : le domaine ne depend de rien. Cette rigueur est un atout sur les projets complexes, et un fardeau sur les projets simples. Utilise MVC pour les petits projets, hexa quand la complexité métier le justifie.
Hexa + DDD : le combo naturel
L'architecture hexagonale et le domain-driven design se completent parfaitement. Le DDD te dit comment modeler ton domaine (entités, value objects, aggregats, bounded contexts). L'hexa te dit comment protéger ce domaine du monde extérieur.
Si tu as suivi la serie Domaines et cycles de vie, tu as deja les fondations DDD. L'architecture hexagonale, c'est la couche structurelle qui donne au domaine un espace protégé pour vivre.
Sur paltemps.fr, on combine systématiquement DDD et hexa sur les projets backend avec une logique métier non triviale. Le DDD seul ne protégé pas le domaine du couplage technique. L'hexa seul ne t'aide pas a bien modeler le domaine. Ensemble, ils couvrent les deux aspects.
Mon conseil pour démarrer
Si tu hesites, commence par un MVC classique avec une regle : pas d'import de framework dans les fichiers de logique métier. C'est deja de l'hexa "light". Quand tu sentiras le besoin de formaliser les interfaces, tu ajouteras les ports. Quand tu voudras tester sans infrastructure, tu ajouteras les adaptateurs in-memory.
L'hexa n'est pas tout ou rien. Tu peux y aller progressivement, une couche a la fois.
Résumé
- L'hexa est fait pour les projets avec une vraie logique métier, plusieurs points d'entree, et une équipe de plus de 2 personnes
- Pour du CRUD simple, un prototype ou un solo-project, c'est overkill
- L'hexa est plus leger que la clean architecture, plus strict que le MVC
- L'hexa et le DDD se completent naturellement
- Tu peux commencer "light" et formaliser les couches progressivement
Article précédent : 06 - Projet complet
Article suivant : 08 - Glossaire
Début de la serie : 00 - Introduction
Serie liee : Domaines et cycles de vie