DDD, Domain Driven Development

La conception pilotée par le domaine (DDD, A.K.A. Domain Driven Design) crée une nouvelle manière de construire les logiciels. Plutôt que de réfléchir à une architecture centrée autour de problématiques techniques, les développeurs et concepteurs mettent le domaine métier au cœur du système avec la volonté forte de décrire le métier… par le code !

DDD, un état d’esprit plus qu’une méthode.

Pour créer un bon logiciel, vous devez savoir de quoi il est question. Si une agence immobilière demande à ce qu’on lui crée un logiciel pour gérer son activité, qui sera capable de connaitre toutes les règles qui régissent le monde de l’immobilier ? L’architecte logiciel, l’analyste logiciel, le chef de projet ou bien le développeur ? Aucun des quatre ! Aucune de ces personnes ne s’y connait en immobilier. Alors qui maitrise ce domaine ? Un agent immobilier bien sûr !

Le système immobilier est très bien compris par les gens de l’intérieur, par ses spécialistes. Ils en connaissent tous les détails, tous les pièges, tous les problèmes possibles et toutes les règles. Voilà par où l’on devrait toujours commencer : le domaine

Lorsque nous débutons un projet informatique, nous devrions nous concentrer sur le domaine dans lequel il opère. Le seul but du logiciel est d’améliorer un domaine spécifique. Pour être capable de faire cela, le logiciel doit se mettre au diapason du domaine pour lequel il a été créé. Sans cela, il introduira des tensions dans le domaine, provoquant des dysfonctionnements, des dégâts, voire même semant le chaos.

Comment peut-on mettre le logiciel au diapason du domaine ?

La meilleure façon d’y arriver est de faire du logiciel un reflet du domaine. Le logiciel doit incorporer les concepts et éléments qui sont au cœur du domaine, et saisir avec précision les relations entre eux. Le logiciel doit modéliser le domaine.

DDD préconise ainsi plusieurs pratiques pour arriver à ce que les développeurs soient au plus proche du domaine lors de la conception du logiciel. Pour cela, il faut tout d’abord bâtir une solide connaissance du domaine en créant un langage commun et compréhensible par tous : le langage omniprésent.

Or, les développeurs ont la tête pleine de classes, de méthodes, d’algorithmes, de patterns, et ont tendance à toujours vouloir faire correspondre un concept de la vie réelle à un artefact de programmation. Mais les experts du domaine ne connaissent en général rien de tout cela. Ils n’ont aucune idée de ce que peuvent être des bibliothèques logicielles, des frameworks, la persistance, et dans bien des cas même une base de données. Ils connaissent leur champ d’expertise particulier.

Remettre le domaine métier au coeur du système

Nous avons résolument besoin de parler le même langage quand nous nous réunissons pour définir le domaine. Quel langage cela va-t-il être ? Celui des développeurs ? Celui des experts du domaine ? Quelque chose entre les deux ? Un des principes de base de Domain-Driven Design est d’utiliser un langage basé sur le modèle. Puisque le modèle est le terrain d’entente, l’endroit où le logiciel rencontre le domaine, il est justifié de l’utiliser comme terrain de construction de ce langage.

Les développeurs et experts métier doivent donc en premier lieu modéliser le domaine de façon très simple avec des schémas basics (pas d’UML) qui pourront être compris par tous. Les concepts qui émaneront de ce modèle définiront le vocabulaire du langage omniprésent.

L’étape suivante consiste à utiliser un ensemble de pratiques et de techniques qui permettrons aux développeurs de faire de la conception logiciel dirigée par le modèle. Fini les architectures « à la papa » en mode « 3 layers » et les singletons dans tous les sens, il est temps de mettre en œuvre un vrai arsenal pour que le code source du logiciel reflète au mieux le domaine.

Parmi ces concepts, nous avons par exemples l’architecture en oignon, la notion de services, d’entrepôts de données, la gestion des entités à travers des agrégats et des objets-valeurs, les règles métiers sont défini par le pattern « specification », etc. Le refactor est aussi au cœur du DDD, nécessitant une bonne isolation pour permettre de revoir le code à tout moment.

Conclusion

Fondamentalement, DDD est le principe selon lequel nous devrions nous concentrer sur les enjeux profonds du domaine dans lequel nos utilisateurs sont impliqués, selon lequel le meilleur de nos esprits devrait être dévoué à la compréhension ce domaine, et à la collaboration avec les experts du domaine pour réussir à accoucher d’une forme conceptuelle que nous pouvons utiliser pour bâtir des logiciels flexibles et puissants. C’est un principe qui ne passera jamais de mode. Il s’applique à chaque fois que l’on opère dans un domaine complexe et très élaboré.