DDD stratégique vs. DDD tactique

[Rediffusion de l'article du 14 décembre 2022.]

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" : quoi faire, sur quoi focaliser notre énergie et le peu de temps dont nous disposons. C'est tout le travail d'identification des bounded contexts (more on that juste après). Puis 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.

• Le DDD tactique, le "comment" : on a décidé d'investir sur ce contexte. Comment s'y prend-t-on ? Quels patterns pour nous aider ? Architecture hexagonale, functional core / imperative shell, ES/CQRS, microservices ?

Un petit 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 — j'y consacre presque 1 journée de formation — mais pour faire simple, un bounded context est un module d'un système d'information plus large.

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, voulez-vous ? 🫖

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 de modularité 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 ça 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 (Golden Master, Mikado, Strangler Fig), ç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 😊

A la semaine prochaine pour le retour à des chroniques inédites !

(*) Subtile référence footballistique, on appréciera.