Conférence

DDDReboot : Et si on reprenait l’histoire par le bon bout? Tout simplement

13 décembre 2016

Comme beaucoup, j’ai commencé le blue book d’Eric Evans sans jamais le finir… Je le trouvais trop complexe. Bref, je m’étais dit le DDD c’est pas pour moi. Quand Thomas et Jérémy ont sorti cette présentation, je me suis dit : « Il faut absolument que j’y assiste » au moins pour vérifier si j’avais raison… ou pas 😉 J’ai raté leur session à la SGCIB, à Devoxx et à NCrafts 🙁

Mais ouf, ils étaient à Agile France! Leur discours m’a donné envie de m’y remettre et m’a montré que c’était tout sauf inaccessible. En voici un résumé.

Pour commencer, leur discours est :

En tant que développeur, la première entreprise va être de chasser les implicites : « Make the implicit, explicit!!! » comme ils disent!
Donc, en français dans le texte : Il va vous falloir
1 – révéler l’intention : au niveau des noms de méthodes, des paramètres, des types du retour, …
2 – identifier les zones de bad code, de code smell c’est-à-dire : repérer les magic numbers (les nombres en dur qui ne signifient rien), les duplications, l’utilisation intensive des types primitifs (un decimal ne conserve par exemple que la valeur d’un montant mais pas la devise), les mix entre métier et tech (gestion d’une exception SQL dans une règle métier), les noms pas clairs du tout, …

Bref, « Make the implicit, explicit! »

Dans son livre, Eric Evans parle de « Value Objects », étrange cette association de mots, non? Thomas et Jérémy proposent l’expression « Value type ».
L’idée des Value type, ou Value Objects, est d’exprimer le domaine, métier évidemment, et d’absorber la complexité. Quelques exemples de value types de la vie de tous les jours : un billet de 10€, un poids de 25 kg, la vitesse de 50 km/h. Tous ces exemples sont des combinaisons d’un chiffre et d’une unité. Dans le code, on retrouvera des objets comme Price ou Speed mais pas decimal ou double.
Les caractéristiques d’un value type sont : immutable, riche en logique, égalité sur les attributs, auto validant.

Le DDD c’est évidemment bien plus que les value types, mais si vous ne devez retenir qu’une notion du DDD : retenez celle-ci! C’est le meilleur ROI du DDD! De plus, sa mise en place peut être progressive, vous amènerez les bonnes pratiques par l’exemple (cf. théorie de la vitre cassée) et enfin, c’est un formidable avaleur de complexité!

Pour en finir avec le code, supprimez les classes managers, helper, utils … elles sont sans intention!

Est-ce que le DDD ce n’est que du code? Si la réponse est posée, la réponse est « Évidemment non! ». Il prône d’utiliser un seul langage, pas le C# ou le java, non! Celui des utilisateurs! En d’autres termes, le contexte est très important car plusieurs mots peuvent signifier la même chose ou l’inverse. Prenons l’exemple d’un client : pour les départements comptabilité, vente ou livraison, la définition d’un client est différente. Une définition de la notion de client est donc indispensable pour chaque département. Pour reprendre l’exemple du billet de 10 euros, votre définition est-elle la même que celle de la banque de France ? Autre exemple, un prix dans le domaine de la finance peut-être un prix de clôture, un prix live, le bid, le ask, …
Mais attention à ne pas tomber dans le piège du modélisme.

Si je vous ai donné envie de tester le DDD, tant mieux! Si vous voulez aller plus loin, la présentation DDDReboot est disponible ici et pour aller encore plus loin, il n’y a qu’à commander le livre d’Eric Evans.

Bonne lecture et bon code!

Ajouter un commentaire


Votre commentaire sera modifié par le site si besoin.

À lire également

Les Web Services d’Amazon (Amazon Web Services), c’était le thème qu’abordait ce summit annuel : une panoplie…

Comme beaucoup, j’ai commencé le blue book d’Eric Evans sans jamais le finir… Je le trouvais trop…

Le 22-23 avril dernier, j’ai étais à mon premier Devoxx Paris, conférence généraliste dédiée aux développeurs. Depuis…