Architecture hexagonale : faut-il encore un ORM ?
Abordons aujourd’hui une question souvent passée sous silence quand on parle d’Architecture Hexagonale : est-il opportun d’utiliser un outil de Mapping Objet-Relationnel (disons « un ORM », par abus de langage) ?
Le problème est le suivant :
L’Architecture Hexagonale vise à isoler le domaine et l’application afin d’éviter une dépendance non souhaitée à l’infrastructure (framework Web, base de données etc.), et par là-même d’en faciliter le test. Elle procède par inversion de dépendances. L’implémentation d’une telle architecture part du domaine : le modèle qui sous-tend le comportement désiré et satisfait les invariants du métier est créé avant toute autre chose.
Or que fait un ORM ? Un ORM fait exactement le contraire : il expose des entités directement mappées aux tables de la base de données et gère leur cycle de vie, décidant lui-même de la lecture et de l’écriture des données (un ORM est d’ailleurs la plupart du temps un framework, cf. « Entity Framework » – au moins, les choses sont claires). Ces entités n’ignorent rien du modèle physique de données : si l’infrastructure change, le domaine doit changer lui aussi.
Autrement dit, architecture hexagonale et ORM sont antinomiques.
Vous pouvez évidemment utiliser l’ORM comme implémentation d’un port secondaire du domaine : des entités métier pures pour représenter le domaine, les repositories exposées par l’ORM pour implémenter le même port. C’est techniquement faisable, mais très lourd et pour quel bénéfice ? En effet, vous conservez les bénéfices de l’architecture hexagonale, mais vous perdez ceux de l’ORM. C’est vouloir ménager à tout prix la chèvre et le chou, ou bien faire rentrer des carrés dans des ronds…
À bien y regarder – j’expose ici une opinion — je trouve d’ailleurs la promesse des ORMs très contestable. Ces derniers vous promettent de ne pas avoir à apprendre le SQL, langage standard des bases de données relationnelles. Sauf que pour ne pas avoir à apprendre ce standard, vous devez apprendre le pseudo-langage propriétaire d’un ORM…
C’est d’autant plus problématique que la promesse n’est tenue que dans 80% des cas, ceux les plus simples : mapping 1-1, une entité mappée à une table, avec éventuellement quelques jointures. Mais tôt ou tard, vous finirez par écrire des requêtes SQL à la main, pour les 20% de cas métier trop spécifiques pour être pris en charge par l’ORM, ou bien pour des raisons de performances.
Que vous adhériez ou non à cette opinion ne change pas une chose : tout est affaire de cas d’usage. Un ORM peut avoir du sens dans le cas d’une application de type CRUD (à supposer qu’une telle application existe, d’ailleurs). En dehors de cela, dès que vous implémentez des vraies règles de gestion, isolées au sein d’une architecture hexagonale, il n’y a plus de place pour un ORM.