(tu meurs d’envie de me traiter de débile en commentaire, mais tu respires un grand coup, et décides de lire le post d’abord)
Évidemment qu’il faut découpler les composants, et le faire là où ils s’échangent des données. Ce n’est pas la question.
Mais observons : les interfaces introduites – prenons les adapters – n’ont souvent qu’une seule implémentation utile en production.
- Une seule base de données
- Un seul service mail
- Un seul file store
- etc.
C’est une preuve que l'abstraction introduite ne soutient aucun requis utilisateur. Il n’y a pas de polymorphisme au sens classique du terme, puisque rien n’est polymorphe at runtime [1].
Introduire une abstraction inutile porte un nom : complexité accidentelle.
Cela dit, ces abstractions supportent les tests unitaires. Cela ne relève pas d'un requis fonctionnel, mais non fonctionnel, p.ex. la maintenabilité – qui n’est pas moins importante.
On a introduit ces pratiques d’abstraction parce qu’assembler le logiciel et l’exécuter est compliqué et lent. Et qu’on préfère pouvoir tester un peu lors du dev que finir par ne rien tester du tout, ou très lentement et très tard.
[...] était compliqué et lent [...]
Nous sommes en 2026. Si assembler et exécuter ton logiciel est compliqué et lent, tu peux invoquer tous les dieux DDD et Hexa, ton problème n’est pas là.
Et si ce n’est pas difficile, tu peux déplacer le curseur des tests vers plus d’intégration et moins d’unitaire, et supprimer certaines abstractions accidentelles.
(maintenant tu peux te lâcher en commentaires mais en comprenant mon argument : je ne suis pas anti-Hexa mais si c’est une manière pour l’équipe d’affaiblir toutes les post conditions par peur des tests d’intégration et une procrastination DevOps, le curseur est mal placé et je doute que l’équipe délivre souvent en production)
un contre-exemple pourrait être de supporter plusieurs providers de paiement et laisser l’utilisateur choisir. On sent bien qu’on est dans un autre cas. ↩︎