Dev.Agile.Stories

Le DDD est issu du savoir-faire d’Eric Evans dans le domaine de la conception de logiciels. La capture de ces concepts à donner lieu à la publication du livre éponyme en 2004.

Le DDD n’est pas une méthode de modélisation mais plutôt une façon de pensée ou philosophie de conception. Même si la pratique de DDD se marie particulièrement bien à un cycle de développement agile via l’extreme programming (XP) et en particulier à TDD cette association ne constitue cependant nullement un pré-requis obligatoire.

Le propos de cette pratique est de focaliser la conception sur le domaine métier et de produire un modèle métier expressif. Un point important de cette philosophie est d’encourager la communication entre les experts métiers et les développeurs afin de partager un langage commun. Le modèle pourra être affiné et refactoré au fur et à mesure des échanges entre les équipes métiers et les équipes de réalisation.

Il faut signaler la différence de philosophie avec la démarche MDA (Model Driven Architecture) ou il est aussi question de modèle, cependant la comparaison s’arrête là, en effet le MDA repose sur des outils de transformation et de génération de code alors que le DDD parle de pratiques de conception et n’impose aucun outil.

Afin de rendre concret le propos voici un exemple pratiqué réel de cycle de développement d’un modèle métier qui s’inspire de DDD.

Le modèle se construit au cour d’un cycle itératif, chaque itération étant fixée à 2 semaines. En début d’itération la capture du besoin se fait entre les experts métier et l’ensemble des développeurs, cette capture des concepts du domaine se fait au travers de « stories » : spécifications concises décrivant les fonctionnalités du domaine. Chaque itération est donc l’occasion de fournir la matière première pour alimenter la mise en oeuvre du domaine. Un aspect important est que cette matière n’est pas livrée d’un bloc aux équipes de réalisation mais au fil des itérations et selon les priorités décidées par les experts métier.

La seconde étape consiste à extraire les nouveaux éléments candidats à la structuration du modèle mais aussi ceux qui peuvent le remettre en cause. A ce stade pas besoin d’outil particulier, un tableau blanc est amplement suffisant. La communication à l’intérieur de l’équipe de réalisation est primordiale, la confrontation des idées garantie la justesse du modèle.

L’implémentation du modèle avec TDD a permis de spécifier finement le coeur du métier, on met ainsi en place un harnais de tests unitaires qui garanti la solidité du modèle quelque soit son utilisation. Le soin apporté à l’écriture de ces tests permet de décrire le modèle à la manière d’une documentation. L’intérêt évident ici est de passer plus de temps à soigner des tests qui colleront de fait toujours à la réalité plutôt que d’entretenir une documentation de conception technique très (trop ?) détaillée et dont la cohérence doit être vérifiée manuellement.

L’implémentation du modèle selon DDD ne consiste pas seulement à coder un modèle anémique avec seulement ses attributs, les règles concernant le coeur du métier sont régulièrement factorisées en poussant  des couches processus / services métier vers la couche modèle, ce qui soit dit en passant simplifie grandement l’écriture des tests.

Le pratique de DDD vient avec certains pattern de conception visant à simplifier les couches et l’utilisation du modèle (repository, builder, helper de test,…), le sujet méritant un article à lui tout seul, je m’efforcerai d’y revenir, ce sera aussi l’occasion de parler des framework que l’on qualifie de « framework de productivité ».

Se pose ensuite la question de « démontrer » un modèle non persistant aux utilisateurs ou tout du moins à ceux qui les représentent. La solution est d’automatiser les stories / spécifications fonctionnelles afin de vérifier au travers d’assertions que le comportement du modèle est bien celui attendu (je ne détaille pas ici les outils, cela pourra faire l’objet d’un article). On peut donc poursuivre une conception du domaine constructive sans pour autant être bloquer par une phase de définition d’architecture technique et de choix de frameworks. Lorsque le domaine est suffisamment étoffé on peut alors envisager de commencer à le persister et de le présenter via un framework web.

La communication entre experts métier et développeurs se fait bien sur pendant la capture du besoin, cependant un autre aspect est extrêmement important : lorsqu’un modèle dérive ou génère des approximations par rapport à la réalité et au vocabulaire métier on obtient généralement du code qu’il faudra refaire et dont la compréhension diminue au fur et à mesure que l’on avance. Sur ce point là, le levier sur la productivité est donc très élevé. Les revues de modèle régulières entre tous les acteurs ont permis de minimiser la distorsion, le modèle est présenté aux experts métier sous forme de diagrammes de classes UML. Les risques d’incompréhension liés au formalisme UML doivent être minimisés sous forme d’échanges qui favorisent le jargon métier par rapport à l’explication des concepts objets sous jacents.

Dernier point, les diagrammes de classes sont obtenus par rétro conception manuelle, un simple outil de présentation tel que Visio est suffisant. Le développement itératif et les revus de modèle minimisent les risques de perte d’information, la pratique a démontré l’efficacité de la démarche.

L’expérience DDD a été pour moi réellement concluante pour construire un modèle métier riche et sans ambiguités. Mais étant donné que DDD n’impose rien en terme de méthodologie et d’outils, qu’est ce qui fait la différence par rapport aux autres techniques ? Il y a bien sur la capture de patterns spécifiques aux couches métier mais rien n’empêche de les retrouver dans des phases de conception plus classique. L’essentiel à mon avis est lié à la proximité entre le garant du métier et celui qui développe.