DDD stratégique vs. DDD tactique

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" : modalités de déploiement (monolithe modulaire vs. microservices) et de communication (orchestration/chorégraphie), puis tous les détails de la mise en œuvre à l'intérieur d'un contexte : architecture hexagonale, functional core / imperative shell etc. Et là, oui, on parle des usual suspects du DDD : entities, value objects, aggregates, repositories, services.

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 modules/contextes minimise ainsi les interactions entre ces derniers, sans pour autant les annuler : les modules 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.

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 modules 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. C'est le "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 module 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 😊