BT

Diffuser les Connaissances et l'Innovation dans le Développement Logiciel d'Entreprise

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Actualités Après-midi DDD & LegacyClub à Paris

Après-midi DDD & LegacyClub à Paris

Favoris

Le Domain Driven Design - DDD est cette pratique inscrivant au coeur de tous nos développements logiciels la valeur et les concepts métiers. C'est même sans doute l'un des principes les plus puissants pour comprendre le métier et aider ainsi à la réussite des projets. C'est également un outil puissant pour retravailler un produit existant.

La communauté française du DDD s'organise et s'agrandit. Bruno Boucard, Thomas Pierrain et Jérémie Grodziski organiseront une après midi du DDD le 7 juin pour en montrer l'usage dans le cadre d'un refactoring d'application legacy. InfoQ FR a pu échanger avec Thomas et Bruno autour du DDD, du lien avec l'architecture, l'usage du DDD pour le refactoring, ainsi que la relation entre DDD et microservices.

 

InfoQ FR : En tant qu'organisateurs de l'après midi du DDD, quel est l'objectif de cette demi-journée ?

Thomas Pierrain : L'objectif de cette après-midi (gratuite et ouverte à tous, quelque soit votre niveau) est de continuer - après le talk DDD reboot - à rendre accessible la "sagesse" du DDD auprès du plus grand nombre. C'est pour pouvoir toucher le public le plus large possible que nous avons proposé à Microsoft de nous héberger pour cette grande fête du "code qui a du sens et de la valeur".

InfoQ FR : Concrètement, quand on utilise déjà du TDD et du BDD, pourquoi utiliser du DDD ?

Bruno Boucard : Ces pratiques sont complémentaires. Le BDD - lorsqu'il est bien compris - nous permet d'avoir des discussions intéressantes avec le métier et orientées "definition of done" (pratique pour nos tests d'acceptance). Le TDD lui, nous permet de coder en objectivant et en cadrant clairement au fil de l'eau nos développements en consolidant sereinement du code de qualité.

En nous poussant à nous intéresser sérieusement au domaine métier pour pouvoir inscrire celui-ci dans le cœur de nos logiciels (code, architecture), le DDD nous transforme en véritables interlocuteurs éclairés, efficaces et pertinents pour nos métiers. On passe ainsi à la vitesse supérieure dans notre façon de pratiquer notre métier et d'apporter de la valeur. C'est très épanouissant, et diablement efficace aussi.

InfoQ FR : En tant que développeur, qu'est-ce qu'implique le DDD dans mon quotidien ?

Thomas Pierrain : Au quotidien, le DDD nous force à nous poser la question de ce qui apporte de la valeur et de ce qui n'en apporte pas (c.ad. la tuyauterie et la complexité accidentelle que l'on créées trop souvent dans nos softs). En nous forçant à utiliser le langage "omniprésent" du métier dans notre code, on évite également un maximum de bugs et d'incompréhensions.

Les "contextes" spécialisés du DDD et le fait de se concentrer sur les usages nous permettent de découvrir qu'on est pas obligé de tout abstraire, tout généraliser, tout factoriser. On devient alors plus concret, plus direct dans notre approche du code.

A l'aide de quelques techniques et patterns de la boîte à outils du DDD, on arrive même à réaliser l'impensable... un code métier qui se distingue clairement du code purement technique (fini donc le legacy spaghetti à la sauce big ball of mud, ou les applications CRUD sans valeurs, voire de notre obsession pour les couches ;-)

InfoQ FR : On vous connaît pour votre activité autour du #LegacyClub. Quels liens entre le DDD et le legacy ?

Bruno Boucard : En premier lieu, le DDD apporte quelques outils pour nous aider à gérer du code "legacy" (par étranglement ou en introduisant un Bubble Context par exemple). Mais c'est surtout en redonnant du sens et une teinte fonctionnelle à notre code existant que l'on arrive à reprendre le contrôle sur celui-ci. Pour ce faire, les quelques techniques que nous montrerons en live coding permettront d'extraire progressivement la logique métier d'un magma assez infame, mais très ressemblant de ce qu'on a l'habitude de voir sur les projets.

La plupart des gens qui introduisent le DDD le font en général à partir d'une page blanche, d'une situation à partir de laquelle on est assez libre et qui ressemble à assez peu de situations projets en définitive. Pour notre événement chez MS, nous avons décidé de partir de ce que les gens connaissent déjà - le code legacy - pour leur montrer très concrètement à quel point la boîte à outils et l'état d'esprit du DDD peuvent aider. C'est là l'originalité de notre événement (ainsi que le fait d'avoir 70% de live coding).

InfoQ FR : Avec la prise de position de Eric Evans sur l'adéquation du DDD et des architectures microservices, comment voyez-vous le lien entre legacy monolithique, DDD et l'orientation microservices ?

Thomas Pierrain : Le DDD introduisait déjà à l'époque la notion de Bounded Context qui définit un périmètre maitrisé, isolé, où l'on partage le même langage, les mêmes définitions. Par "périmètre maitrisé", on fait ici référence au code, aux formats et modèles d'échanges entre les systèmes, aux bases de données, etc. La maîtrise des périmètres de ces contextes est un sujet compliqué car il résiste souvent mal au temps et au turn-over dans les équipes (les nouveaux arrivants qui ne connaissent pas encore très bien les différents Bounded Contexts pouvant plus facilement les violer en tirant des dépendances dans le code et les librairies au lieu de les maintenir isolés).

Le propos d'Eric est de dire que puisque les frontières logiques (modules, librairies, etc.) ne résistent pas au temps et deviennent poreuses, l'avènement des micro services est une formidable opportunité pour établir des frontières physiques (avec des web API et du réseau) plus solides pour les contextes que l'on veut maintenir bounded à travers le temps et les turn-over.

Attention toutefois : cela ne signifie pas qu'un Bounded Context corresponde forcément à un micro service comme nous l'entendons malheureusement ici ou là. Un (Bounded) Context peut tout à fait être le siège de plusieurs activités, chacune d'entre-elles pouvant être implémentée par un micro-services (ou pas ;-). En d'autres termes et pour être plus clair : un Bounded Context sera vraisemblablemnent constitué de plusieurs micro-services.

Ce qui est sûr, c'est que lorsqu'on s'attaque à un legacy monolithe pour le refactorer, on va en général tâcher de le découper au mieux pour éviter le big ball of mud (appellé aussi le BLOB, plat de spaghetti...). Mais cette découpe peut-être soit logique, soit physique. Vous n'êtes pas condamnés à n'implémenter que des micro-services ;-)

Bruno Boucard : Justement, retrouvez-nous le 7 juin prochain pour voir quelles techniques utiliser pour comprendre et extraire la valeur métier d'un gros tas de code legacy. Inscription gratuite ici.

Evaluer cet article

Pertinence
Style

Contenu Éducatif

BT