Le Domain Driven Design est-il adapté à tous vos projets ?

Voilà une question qui revient régulièrement : le Domain Driven Design est-il adapté à tous les projets de développement logiciel ?

Pour moi, la partie stratégique du DDD est indispensable pour tout développement.
Je vois mal comment nous sommes censés développer une application sans chercher à comprendre le contexte métier dans laquelle elle va s’inscrire. Et le DDD c’est exactement ça : comment j’aligne les aspects techniques avec le métier que je dois implémenter ?
Et c’est pour ça que je dis souvent que je peux pas développer sans faire du DDD.
Cela veut simplement dire que je ne peux pas développer une application sans prendre un peu de recul et comprendre ce que je dois développer.
Je sais pas ce que vous en pensez, mais je trouve que c’est un réflexe plutôt sain.

Par contre, en fonction du contexte métier (et du contexte technique) les patterns tactiques, et les patterns d’architectures souvent associées au DDD ne sont pas à mettre à œuvre systématiquement.
En effet, comme pour n’importe quel design pattern ou architecture, l’objectif du DDD ce n’est pas de tout mettre dans tous vos projets. Au contraire, ce type d’approche va à l’encontre même de la philosophie du DDD.
Les patterns d’architectures sont un peu comme si nous avions une boite à outils à notre disposition. En fonction du problème à résoudre nous pouvons donc aller piocher dans cette boite à outils pour résoudre le plus efficacement possible ce problème.
Mais nous ne sommes pas là pour utiliser toute la boite à outils sur tous les projets. Parfois même, aucun de ces outils n’est adapté à la situation.

Je pense que l’erreur vient souvent de la confusion entre faire du DDD, c’est-à-dire s’intéresser au contexte métier pour une application donnée, et utiliser les patterns et les architectures associées au DDD.
Utiliser un repository pour sauvegarder des agrégats, ça n’est pas faire du DDD. C’est « juste » que vous utilisez les patterns tactiques du DDD.
D’ailleurs, beaucoup de projets utilisent ces patterns sans réellement faire du DDD, car les développements se font sans avoir cherché à comprendre le contexte métier sous-jacent.

Enfin un dernier point : le DDD comporte une grande part d’heuristiques. C’est donc l’expérience du praticien et de l’équipe qui s’exprime dans ce type de démarche.
C’est pourquoi il est important de lire la littérature disponible sur ce sujet. Mais cela ne sert à rien s’il n’y a pas une expérience sur de vrais projets qui va avec.
Or, je vois trop souvent des experts DDD autoproclamés qui n’ont malheureusement lu que les livres et jamais réellement mis en application la démarche dans plusieurs contextes professionnels. Pour réussir à gagner une expertise dans ce domaine il est important d’avoir eu l’occasion de l’appliquer sur plusieurs projets distincts.
En effet, ça n’est qu’en collectant des expériences dans des domaines métiers différents avec des contextes techniques spécifiques, que nous pouvons comparer les différentes manières d’aborder un problème et donc de pouvoir sélectionner la solution la plus adaptée.

Pour conclure, il me parait important de rappeler qu’une démarche de DDD va bien au-delà de l’équipe technique, elle doit inclure l’ensemble des parties prenantes du projet.
Et c’est souvent ce dernier point qui est le plus difficile à obtenir, bien au-delà de la simple maitrise des outils que nous propose cette approche.