DDD stratégique vs. DDD tactique
Définitions
Le Domain-driven design (DDD) est un vaste champ de savoir, au sein duquel on distingue généralement 2 grands volets. Les termes sont issus du monde militaire :
-
Le DDD stratégique, le « quoi » : cela commence par la cartographie du territoire, c’est-à-dire l’identification des contextes du système d’information (more on that juste après). Vient ensuite la décision stratégique de développer tel contexte parce qu’il est cœur de métier, et d’utiliser un produit ou service du marché pour tel autre, qui ne l’est pas. Pour l’image, disons que c’est Napoléon qui décide d’envahir la Russie — mais je vous souhaite plus de succès que lui.
-
Le DDD tactique, le « comment » : c’est là qu’on retrouve tout le savoir-faire propre à la modélisation à l’aide d’entities, aggregates, value objects, repositories et de services, et par extension l’architecture hexagonale. Vous voulez un domaine qui n’en fasse ni trop (modèle obèse) ni trop peu (domaine anémique). Sa responsabilité est d’implémenter les invariants du métier, sans empiéter sur la responsabilité des use-cases, qui assurent la coordination applicative.
Rappels sur la modularité : les bounded contexts
Un rappel pour ne laisser personne sur le banc de touche : il faudrait un peu plus de temps pour vous donner l’intuition de ce qu’est un bounded context, mais on peut dire en première approche qu’un contexte est un module fonctionnel. D’ailleurs, on parle bien de « modularisation ».
Le découpage d’un système d’information en contextes minimise ainsi les interactions entre ces derniers, sans pour autant les annuler : les contextes doivent communiquer, un peu. Autrement dit, tout autre découpage donnerait lieu à plus d’interactions, et ça on n’aime pas parce que ça finit en plat de spaghettis 🍝
Pour être concret, un contexte traduit une action. « Customer » ne sera jamais un contexte, car je peux faire mille choses avec un client : lui vendre un réfrigérateur, lui expédier ledit réfrigérateur, facturer le client ou bien encore assurer le service après-vente parce qu’il n’est pas sûr que la lumière s’éteigne bien quand il referme la porte du frigo. 4 actions correspondant à 4 contextes bien différents.
Mais reprenons le fil de notre discussion.
Le stratégique avant le tactique
La plupart des ressources disponibles sur Internet traitent des sujets tactiques. Malheureusement, aborder le DDD sous cet angle, c’est voir les choses par le petit bout de la lorgnette.
En effet, mener une réflexion stratégique sans aller dans tous les détails de la mise en œuvre, ce n’est pas très grave. Si là ou là vous n’avez pas l’architecture hexagonale « qui va bien », il sera toujours temps d’y venir plus tard. C’est même précisément le rôle de la stratégie d’établir des priorités et une chronologie. Si, déjà, les frontières des contextes sont claires dans notre esprit, c’est beaucoup.
En revanche, la tactique sans la stratégie, ça a peu de chance de marcher, par définition. Procéder ainsi serait équivalent à dire « on ne sait pas où l’on va, mais on y va ». C’est poser des fenêtres sur une maison dont on n’a pas achevé les fondations. Vous avez compris. Faire de belles architectures hexagonales, mettre en place une communication événementielle, tout cela devra être cassé s’il s’avère que les contextes sont mal définis.
La bonne nouvelle, c’est que le DDD stratégique ne coûte pas cher. Ce sont des interviews, de l’analyse sur papier, des « diagrammes de patates » et 1 ou 2 semaines d’intense réflexion. OK, parfois un peu d’accompagnement car il y a quelques réflexes à avoir, mais cela permet de clarifier rapidement la vision à la cible.
Ensuite, on refactore petit à petit. Et avec de la méthode (Strangler Fig, Mikado, Golden Master), ça peut se faire en douceur.
Ce travail, on ne le fait jamais assez tôt : même si vous ne développez qu’un premier contexte de votre produit, c’est bien de savoir que telle autre fonctionnalité nous emmène tout de suite vers un autre contexte.
Ça évitera beaucoup de dette technique 😊