Comparatif
Trois réponses à trois questions différentes
Hexagonale, Clean Architecture et DDD sont presque toujours présentés comme des choix concurrents. En réalité, ils répondent à des questions différentes et se combinent naturellement dans la plupart des projets sérieux.
| Hexagonale | Clean Architecture | DDD | |
|---|---|---|---|
| Auteur, année | Alistair Cockburn, 2005 | Robert C. Martin, 2012 | Eric Evans, 2003 |
| Question posée | Comment isoler le métier de la technique ? | Dans quel sens doivent pointer les dépendances ? | Quel modèle mettre dans le métier, et comment le découper ? |
| Unité centrale | Le domaine, au centre de l'hexagone | Les Entités, au centre des cercles | L'agrégat, à l'intérieur d'un bounded context |
| Vocabulaire de la frontière | Ports (entrants / sortants) et adaptateurs | Adaptateurs d'interface, règle de dépendance | Context mapping (ACL, Shared Kernel, Conformist...) |
| Ce que ça garantit | Le métier se teste sans framework ni base de données | Aucune dépendance ne pointe de l'intérieur vers l'extérieur | Le code parle le même langage que les experts métier |
| Point faible si mal appliqué | Ports qui recopient un schéma SQL (CRUD déguisé) | Sur-découpage en couches sur une app triviale | Patterns tactiques sans langage omniprésent ni bounded context |
Comment elles s'articulent
Le DDD répond à la question du contenu : qu'est-ce qui doit vivre dans le cœur du système, et comment le découper en modèles cohérents (bounded contexts) ? L'hexagonale et Clean Architecture répondent à la question de la structure : comment protéger ce cœur, une fois défini, de tout ce qui l'entoure ?
Concrètement, les entités et agrégats du DDD occupent exactement la place du noyau hexagonal ou du cercle "Entités" de Clean Architecture. Les repositories que le DDD définit comme faisant partie du domaine sont des ports sortants au sens hexagonal. Rien ne s'oppose entre ces trois approches - elles décrivent le même bâtiment sous trois angles différents.
Par quoi commencer ?
Toujours : le langage omniprésent
Discuter avec les utilisateurs du système et nommer le code exactement comme eux nomment les choses ne coûte rien et évite la majorité des malentendus, quelle que soit la taille du projet.
Presque toujours : ports et adaptateurs
Isoler le métier derrière quelques interfaces simples rend les tests rapides et le changement de technologie moins risqué, même sur une application de taille modeste.
Seulement si le métier est vraiment complexe : agrégats, bounded contexts multiples
Ces patterns ont un coût de conception réel. Ils se justifient face à une complexité métier authentique (règles nombreuses, invariants stricts, équipes multiples) - pas sur un CRUD avec trois écrans.