Le DDD pas à pas

Lors de la 11^ème édition de la Devoxx Paris, organisée au Palais des Congrès, le 12 avril 2023, Arnaud THIEFAINE et Dorra BARTAGUIZ ont présenté une conférence intitulée « Rendons le DDD aux devs ».

Dorra est VP Tech chez Arolla, co-auteure du livre “Software Craft : TDD, Clean Code et autres pratiques essentielles” aux éditions Dunod.

Arnaud est développeur, coach craft et formateur chez Arolla. Il est également co-auteur du livre Software Craft.

Lors de la conférence University qui a eu lieu le premier jour de la Devoxx durant 3 heures, Dorra et Arnaud ont commencé en présentant un Kata de modélisation qu’ils ont créé. Avec un thème sur le théâtre, le Kata contient une fonction de réservation de siège avec un calcul des tarifs et un export en XML. Il est également possible d’avoir une carte de souscription qui permet au détenteur de bénéficier de tarifs réduits.

Comment bien refactorer un code legacy ?

Dans un premier temps, ils ont présenté un code legacy avec une méthode réservation() de plus de 140 lignes peu lisibles. Ils ont commencé par refactorer le code en utilisant les fonctionnalités de l’IDE afin de faire ressortir quelques concepts du DDD et essayer de séparer le code métier du code technique.

Faire du refactoring du code n’est pas sans danger car on peut facilement casser les fonctionnalités existantes. C’est pourquoi la première règle à suivre est la création des tests et surtout avoir une très bonne couverture de code afin d’éviter de faire des régressions et d’introduire des bugs.

Pendant la 1ère partie de la présentation, Dorra et Arnaud ont montré comment extraire une value type à partir du code legacy. Cela est fait en extrayant le code dans une méthode et en le déplaçant dans une autre classe après. Ils ont ainsi introduit les notions d’Amount et de Rate qui étaient représentées avant par plusieurs opérations en utilisant la classe BigDecimal.

Ils ont également expliqué ce qu’est un DSL « domain-specific-language ». En effet un DSL est une grammaire métier qu’on introduit dans notre programme de programmation sous la forme d’API. L’avantage d’un DSL est qu’il encadre les fonctionnalités que nous avons, et surtout qu’il protège de ce que nous ne pouvons pas faire. L’exemple qu’ils ont utilisé pour démontrer cela était d’identifier les opérations arithmétiques et de les extraire dans des méthodes de la classe Amount.

Par exemple :

Amount multiply(Rate rate) : fonction qui permet de multiplier un prix par un ratio.

Amount add(Amount other) : fonction qui permet de faire la somme de deux prix.

Ils ont également souligné qu’il est très important de nommer correctement les méthodes et les variables pour faciliter la compréhension du code et ainsi éviter d’ajouter des commentaires inutiles.

Dans une seconde étape, Dorra et Arnaud ont présenté le pattern sandwich. C’est un pattern de refactoring. L’idée est de regrouper tout le code métier au centre (cela représente les ingrédients du sandwich) et la technique aux extrémités (cela représente les tranches de pain du sandwich) parce que souvent dans nos projets on a du code métier et du code technique qui sont entremêlés.

L’objectif est d’éviter les éléments de code qui contribuent à des responsabilités différentes et qui finissent par se retrouver croisés.

Par conséquent, il est très important d’avoir un code propre en effectuant les actions suivantes :

La suppression des variables non utilisées.
La suppression des commentaires.
La suppression des écritures console « System.out.println() ».
Le rapprochement de la déclaration des variables de leurs utilisations.

Intégrer le domaine dans notre code permet qu’il soit facilement lisible par quelqu’un qui n’est pas développeur. Ça permet aussi d’échanger avec le métier beaucoup plus facilement.

Quelles sont les techniques utilisées pour identifier les « Bounded Contexts » ?

Il existe différentes techniques pour identifier les domaines métier afin de ressortir les « Bounded Contexts ».

Une de ces techniques est « Event Storming ». C’est un atelier. Ce type d’événement est habituellement effectué en une demi-journée. Il inclut toutes les parties prenantes du projet, c’est-à-dire les développeurs, les Product Owner et les experts métiers. Le but est d’identifier sur un tableau et à l’aide des post-its tous les évènements et les acteurs du projet.

Si vous voulez en savoir plus sur le déroulement d’un atelier « Event Storming », nous en parlons dans cet article « Domain Driven Design Part 4 – Les pratiques ».

Ce genre d’événement demeure difficile à organiser car il est difficile de mobiliser les experts métiers et les Product Owner pendant si longtemps.

Dorra et Arnaud ont ensuite présenté une autre technique pour identifier les domaines métier. Cette technique est définie par les 3 étapes suivantes :

Repérer les sons dans la prononciation des mots, car dans certains cas, il s’agit d’un domaine métier :
- « tion » dans le cadre d’un projet en français
- « ing » dans le cadre d’un projet en anglais
Lister les personnages / acteurs : cela aidera à identifier les différents « Bounded Contexts ».
L’Identification des synonymes : en effet dans un projet, nous avons généralement recours à plusieurs terminologies pour dire la même chose. Voilà pourquoi il est important d’identifier les vrais synonymes des faux.

L’architecture Hexagonale

L’idée principale derrière cette architecture est d’isoler le domaine (Métier) et de le protéger. Le domaine est donc considéré comme le code le plus précieux du projet.

Figure 1 : Architecture Hexagonale – Source blog Invivoo

En implémentant l’architecture hexagonale, le domaine est isolé et il est ainsi plus facile de faire des migrations techniques. Par exemple, si on veut faire une migration technique comme aller sur le cloud, il suffit de changer les adaptateurs. On ne touche pas donc à la partie métier.

Cette architecture facilite également la testabilité du domaine puisque celui-ci est bien isolé.

Vous trouverez un article à ce sujet dans le blog d’Invivoo intitulé « architecture hexagonale ».

Dorra et Arnaud ont ensuite présenté les pattern tactiques DDD suivants :

Spécification
Repository
Aggregate
Value Object / Entity
Service

Tout au long de la conférence, Dorra et Arnaud ont mentionné plusieurs références à des livres sur le thème de la DDD, comme le livre bleu d’Eric Evans intitulé « Domain-Driven Design ». C’est le premier livre qui fait référence sur le DDD. Plusieurs autres livres sont apparus par la suite, comme « Implementing Domain-Driven design » de Vaughn Vernon.

Vous pouvez voir et revoir la vidéo de la conférence « Rendons le DDD aux devs » de Dorra BARTAGUIZ et Arnaud THIEFAINE sur youtube.