Le DDD, Domain Driven Design, laisse une impression qui amène souvent à une des remarques suivantes :

• J’en ai déjà entendu parlé … – (mais je ne sais pas ce que c’est)
• Je crois l’avoir vu dans le TDD …
• C’est comme le MDA? – ça marche avec un ensemble de sigles MDSD, MDD
• Hein? T’as un problème avec ta touche « D »

L’objectif de cet article est de vous présenter le DDD, ses enjeux et son intérêt.

Dans DDD, il y a Driven Design, c’est donc une technique de conception. Il ne faut pas confondre avec les techniques de développement (Driven Development) comme par exemple le TDD (Test Driven Development).

DDD n’est ni une méthode ni une technologie. DDD est une manière de penser la conception autour du code, de collaborer et de communiquer avec les experts fonctionnels.

Cet élément de communication est une dimension importante. C’est pourquoi nous aborderons dans cet article les thèmes suivant :

• Qu’est ce que la conception, quel en est l’état actuel
• Qu’est ce qu’apporte le DDD aux techniques plus classiques de conception
• Qu’est ce qu’apporte le DDD à la communication des équipes

Qu’est ce que la conception logicielle

Une définition

La conception logicielle soulève de nombreuses questions. Dans le cadre de notre article, la conception peut être considérée comme une manière de concevoir et d’implémenter un ensemble de fonctionnalités en respectant un ensemble de considérations.

Il existe de nombreuses considérations plus ou moins importantes suivant les contextes et les organisations : Adaptabilité, coût, compatibilité, maintenabilité, modularité, performance, productivité des développements, qualité, réutilisabilité, robustesse, sécurité, simplicité, testabilité, ergonomie, utilisabilité, …

Il faut donc choisir les considérations et les prioriser afin d’orienter la conception. La conception peut imposer de mettre en place une méthode (processus, livrable, formalisme) et/ou des techniques afin de concrétiser la conception lors de l’implémentation en code source.

Pourquoi concevoir?

Au fil du temps, les progressions technologiques nous ont permis de construire des programmes de mieux en mieux structurés. Programmes qui d’ailleurs eux aussi évoluent vers des logiciels au fonctionnement de plus en plus complexes. Nous avons donc évolué de l’assembleur au Java en passant par le C et le C++. Aujourd’hui, afin de construire des applications de gestion, il est commun d’utiliser un langage qui implémente les concepts de la programmation orientée objet (POO) comme Java ou C#.

Afin de prendre en compte la complexité croissante des applications, il faut avoir un plan d’actions de développement avec une conception.

Le chemin est long entre les fonctionnalités demandées et décrites dans un logiciel et l’implémentation avec le paradigme objet et un langage OO. Il y a énormément de liberté pendant la phase conception. La POO ne nous guident pas assez lors de la conception.

Ainsi, avec un tel modèle, les techniques de conception de la POO ne garantissent pas une bonne conception, il faut donc des concepteurs très talentueux !

Qu’est ce qu’une bonne conception?

En premier lieu, une bonne conception permet de développer un logiciel qui répond aux fonctionnalités demandées. Idéalement, elle permet l’évolution et la maintenance du logiciel. Les évolutions ne doivent pas remettre en question toute la conception et l’implémentation. Une bonne conception est un ensemble de considérations comme par exemple la flexibilité, la robustesse ou la maintenabilité suite à des évolutions et des corrections.

Pour tendre vers une bonne conception, une stratégie est de découper l’application en modules en suivant la règle « diviser pour mieux régner ». Ces modules suivent des règles à respecter :

• Responsabilités identifiées dans des modules nommés
• Collaboration et interfaces entre les modules (Pour l’amélioration de la qualité, gérez vos dependances)
• Cohésion forte entre les modules
• Couplage faible entre les modules

Il existe de nombreux travaux et ouvrages sur la conception de personnes reconnues comme expert dans le domaine comme Bertand Meyer, fondateur du langage objet Eiffel, Robert C. Martin, ou encore Martin Fowler. Leurs travaux sont résumés dans le document Principes avancés de conception objet.

Présentation du DDD

Le DDD a été introduit par Eric Evans en 2003. Il a construit cette approche de conception suite à des retours d’expérience. Le DDD est centré sur le métier de l’application et le code source qui l’implémente.

Si vous êtes prêts à suivre les prédicats suivants :

• Vous vous préoccupez du domaine métier et de sa logique,
• La complexité du domaine métier devrait se refléter dans le modèle.

Le DDD vous aidera :

• En développant des applications investissant sur le métier du SI,
• En donnant une expressivité métier à votre code source,
• En faisant communiquer les développeurs et les experts fonctionnels,
• En vous fournissant des techniques de conception (pattern du DDD, refactoring continu),
• En vous proposant des solutions pour organiser une équipe de développement et même un ensemble d’équipes de développement qui collaborent entre elles.

Le DDD est une manière de penser et de communiquer les problèmes et leurs solutions, entre les équipes techniques et fonctionnelles.

La conception est conduite par un modèle. Ce modèle est en partie constitué d’un langage de communication commun aux experts fonctionnels et aux équipes de développement.

Les avantages d’avoir un Domain Model sont :

• Créer un modèle commun et intelligible entre les équipes fonctionnelles et les équipes techniques
• Le modèle est modulaire, flexible et maintenable car il doit refléter la conception fonctionnelle
• Améliorer la testabilité et la réutilisation des objets métiers.

Cela conduit aussi les équipes de développement à investir sur le fonctionnel des applications d’entreprises.

Comprenons le fonctionnel et communiquons avec ses termes

Il faut tout d’abord que les développeurs se familiarisent avec le fonctionnel. Pour cela il faut une communication privilégiée entres les développeurs et les fonctionnels :

• Un langage de communication (commun),
• Des lexiques de termes métier.

On dit que l’on forme l’Ubiquitous Language.

Ces termes se retrouveront tels quels dans le code source. De manière générale, les développeurs doivent apprendre et monter en compétence sur le fonctionnel afin de concevoir au mieux le domaine métier des applications.

Le DDD n’impose ni formalisme ni méthode pour acquérir ce savoir. L’interview d’expert fonctionnel par des développeurs peut être une solution. La communication entre ces deux entités doit être continue tout au long du projet.

Ce modèle apporte donc aux applications développés avec le DDD :

• La communication (et donc la connaissance partagée)
• La maintenabilité
• La simplicité
• La réutilisabilité

Un langage de communication commun

Il existe des incompatibilités de vocabulaire entre les développeurs et les experts fonctionnels :

• Un développeur parle avec des termes techniques :
• algorithmes,
• paradigme objet (objet, encapsulation, héritage, polymorphisme),
• méthodes,
• Design Patterns,
• Framework, libraires.
• L’expert fonctionnel ne connait pas ces termes, et il n’en a pas besoin pour réaliser son travail. Il est compétent sur le domaine fonctionnel.

Il faut un langage commun de communication entre ces deux types de population. Il faut créer un Ubiquitous Language. Ces termes se retrouveront directement dans le Domain Model et donc dans le code source.

Il y a des pièges à éviter. Par exemple, si les spécifications sont en français et que les conventions de nommage des artefacts de programmation sont en anglais, différentes erreurs peuvent survenir :

• mauvaises traduction de la spécification à l’implémentation (nom des classes, méthodes, etc)
• traductions ambiguës,
• traductions erronées,
• traductions dupliquées,
• etc.

Les développeurs doivent réutiliser le jargon des experts fonctionnels dans leurs explications et dans le code source.

Ce langage de communication permet :

• Construire et cultiver un langage commun : en interviewant les experts fonctionnels par exemple,
• Capturer la connaissance du domaine fonctionnel,
• Distiller le modèle : « dé-scoper » ce qui n’est pas primordial dans la conception du modèle, revenir dessus lors d’une prochaine itération,
• Produire le code, reboucler avec les experts fonctionnels pour enrichir le modèle avec des termes qui ont dû être explicités lors du développement

A venir

Les choses importantes à avoir en tête lorsque l’on parle du DDD sont :

• DDD n’est ni une méthode ni une technologie, c’est une manière de penser la conception autour du code source,
• Le modèle du DDD est composé d’un langage de communication, d’une conception et de son implémentation,
• Ce langage de communication doit être intelligible, partagé, adopté et enrichi par les développeurs et les fonctionnels. Pas de transformation de langage, ne rajoutons pas de difficultés,

Vous l’aurez remarqué, le DDD est une approche de conception non intrusive, mais ne résout pas tous les problèmes. Cela a pour grand avantage d’avoir une manière de concevoir flexible et évolutive tout en respectant un certain nombre de pratiques déjà adoptées et éprouvées dans vos équipes. Par exemple, elle peut être associée à UML et/ou TDD sans que cela soit une obligation.

De plus, le DDD ne nécessite pas d’atelier logiciel particulier, n’impose pas de formalisme et n’impose pas non plus de méthode de développement.

Dans un prochain article nous verrons comment concevoir une application avec les techniques proposées par le DDD.

Références à ne pas manquer à propos du DDD :

• Domain Driven Design : What is? : Portail officiel d’information sur le DDD maintenu en autre par Eric Evans
• Domain-Driven Design: Tackling Complexity in the Heart of Software : livre de référence sur le sujet d’Éric Evans
• Groupe Yahoo sur le DDD : site très actif où il y a de nombreuses questions/réponses sur le DDD
• InfoQ Book: Domain Driven Design Quickly : ebook gratuit de Floyd Marinescu qui fait présentation assez détaillée du DDD (nécessite un compte InfoQ), attention ce n’est pas un résumé
• POJO in action : livre de Chris Richardson qui consacre une partie très pratique sur le DDD, comment implémenter le DDD avec les frameworks actuels, une référence