La conception pilotée par le domaine
Le DDD (Domain-Driven Design ou conception pilotée par le domaine en français), voila maintenant quelques années que j’en entends parler. Le plus souvent en ventant les mérites de cette approche. Pourtant je ne l’ai jamais pratiqué, ni même vu appliqué ou utilisé dans les différents projets sur lesquels j’ai travaillé. J’ai donc décidé à m’y intéresser de plus près.
J’ai donc commencé par effectuer des recherches pour trouver des ressources et en apprendre plus sur le sujet. Les nombreuses recherches que j’ai pu mener, m’ont systèmatiquement redirigé vers un ebook : Domain-Driven Design Vite Fait. “Ce livre est une introduction rapide sur les fondamentaux de DDD. Il n’introduit pas de nouveaux concepts. Il essaye de résumer l’essentiel de DDD en se basant principalement sur le livre d’Eric Evans” (l’auteur de DDD).
Je dois dire que je suis plutôt séduit par l’approche proposée. DDD est une méthodologie, une façon de concevoir une application, il n’y a absolument rien de technique dedans. La méthode se base sur la création d’un langage commun (utilisé entre les différents membres du projet, qu’ils soient techniques ou non). Ce langage commun permet ainsi de lever toutes ambiguïtés dans les conversations. Il est aussi impératif que ce langage se retrouve dans la modélisation du code du projet. Le gros avantage de cette façon de travailler est que les développeurs, chefs de projet et les personnes concernées utilisent les mêmes mots pour s’exprimer et désigner un concept précis. La communication est alors améliorée puisque tout le monde discute de la même manière et avec les mêmes mots.
Bien entendu, ce langage (dit omniprésent) peut être amené à évoluer, soit parce que le besoin métier évolue lui-même, soit parce qu’un nouveau concept qui n’avait pas été détecté apparaît. De ce fait, la modélisation de l’application doit évoluer en conséquence et une étape de refactoring sera nécessaire.
Un projet utilisant la conception pilotée par le domaine est donc voué constamment à évoluer et à subir une refactorisation continue. Afin de garantir l’évolutivité et la maintenance de l’application, il sera nécessaire d’implémenter de nombreux “design pattern” afin d’être le plus flexible possible. Il aura également la création de nombreuses classes afin de représenter les différents objets et éléments du domaine de la manière la plus explicite possible.
Cela entrainera une certaine complexité technique qui freine certains développeurs à utiliser cette méthode. Cette même complexité, fait que DDD n’est pas adapté pour de jeunes développeurs. Par contre cela peut être très constructif pour ce dernier s’il est accompagné dans son travail et que ce dernier est validé (par la mise en place de revues de code par exemple).
Pour ma part, je suis convaincu de l’aspect bénéfique de cette approche de conception pilotée par le domaine. Bien sûr elle ne s’appliquera pas à tout type de projet, mais peut-être très efficace dans des applications métiers complexes. En plus de l’aspect projet, cela peut être un très bon moyen de faire progresser de jeunes développeurs.