Pour beaucoup de développeurs, voir un dossier “Domain” dans le code source d’un projet, visant à isoler la partie métier, et avoir des objets riches avec un nommage cohérent, c’est faire du DDD (Domain Driven Design). C’est certes un bon début, mais réduire le Domain Driven Design à une structure de dossier, c’est passer à côté de l’essentiel.
Le DDD, ce n’est pas qu’une affaire de découpage et d’organisation technique. C’est avant tout une approche stratégique. Identifier les différents sous-domaines, comprendre lesquels portent réellement la valeur de l’entreprise, construire un langage commun entre développeurs et experts métier. Tout cela se passe bien avant d’écrire la moindre ligne de code.
Les patterns tactiques ne sont que la partie émergée de l’iceberg. La vraie force du DDD réside dans le travail en amont: aligner le modèle de code sur la réalité du métier et faire en sorte que tout le monde parle le même langage.
Je n’ai que trop rarement vu des équipes embrasser les patterns stratégiques du DDD: définition et mise en place du langage commun (Ubiquitous Language), atelier de “context mapping” (cartographie des domaines et sous-domaines) ou d’“event storming” (modélisation d’un domaine métier en identifiant les événements clés). Au-delà de la technique, c’est pour moi ce qui fait la valeur de la conception pilotée par le domaine.
Parce que ranger son code dans un dossier “Domain” sans faire un travail de fond sur le métier, c’est confondre la technique avec la méthode.
