Bienvenue sur le podcast Artisan Developer, l'émission pour les programmeurs qui veulent
vivre une carrière épanouissante. Prêt à passer au niveau supérieur ? C'est parti !
Aujourd'hui, je suis avec Thomas Pierrein. Thomas, bonjour.
Bonjour.
Je te propose qu'on parle du DDD et c'est un peu ton Mojo, ton Dada, le truc qui t'éclate.
Est-ce que tu peux déjà nous dire ce qu'est pour toi le DDD en quelques mots pour le préciser aux
auditeurs ?
Ok, alors le DDD, c'est un acronym pour Domain Driven Design, qui est quelque chose qui a été un
concept publié par Eric Irans il y a quelques années, c'est un bouquin qui s'appelle le Bluebook.
Donc en gros, c'est à la fois une approche et à la fois une boîte à autiche. Donc l'approche,
c'est grosso modo dire qu'il faut mettre plus de métier dans notre code. Si on va être efficace,
il faut qu'on colle un peu plus aux besoins et aux problèmes et donc dans ce cas-là, il faut vraiment
être collé à ça, donc mieux comprendre et donc le métier, il transpire de tout ce qu'on fait.
Ça c'est l'approche. La boîte à outils qui est dans le bouquin, elle a deux étages. Il y a un
étage au niveau du code, donc là c'est tout un tas de patterns, on appelle tactiques, pour faire ça.
Et puis il y a un étage un peu plus d'architecture ou de travail avec différentes équipes qui étaient
la vraie nouveauté du demand-a-van design qui s'appelle le niveau stratégique. Donc là,
c'est la première fois, il me semble, où on a même explicité les relations de pouvoir entre équipes.
Tu sais, je sais pas si tu es arrivé de travailler sur un projet où tu dépend du travail d'autres
équipes dans une grosse organisation ou pas, mais bien souvent ces relations de pouvoir et de dépendance,
on va avoir un impact à l'exécution. Donc là, c'est un peu un manuel, un guide de survie pour
survivre et être capable d'apporter de la valeur, de faire certains services, même si une des équipes
dont tu n'es pas, ne connaît pas ton existence ou alors tu connais et n'as pas du tout envie de t'aider.
Donc ça va apporter des patterns et des aides pour le travail,
venir entre différentes équipes. A la base, Eric-Evan, il en est vu au D&D,
parce qu'il travaillait dans une boîte, je crois, une institution financière ou une banque,
et il se rendait compte qu'il y avait des équipes qui étaient très performantes,
alors il faisait de l'extrême programming à l'époque et il constatait qu'il y avait des équipes
vraiment qui déboitaient, et puis il y avait d'autres équipes qui étaient soumises à plus de contraintes,
plutôt que des back-offies, etc. avec beaucoup de contraintes et qui allaient beaucoup moins vite.
Et donc il s'est posé la question, mais comment je peux faire en sorte que les équipes vont moins vite,
quelque soit les raisons, ne ralentissent pas les équipes qui vont aller plus vite.
Et donc il s'est posé ces questions-là, de couplage, de dépendance,
comment on peut faire pour s'isoler. Et donc il y a cette notion d'autonomie,
en fait, la prise d'autonomie est un truc important dans le domaine de mon design,
que tu as retrouvé dans l'architecture.
Du coup, tu réponds presque à la ou en moins que tu aies une autre réponse,
j'en sais rien, mais si là, tu t'imagines dans la peau dans des auditeurs qui ne connaît pas ou peut le ddd,
quelle peut être la raison numérante de s'y intéresser ?
Alors déjà l'efficacité, si en tant que dev, tu es à l'archère de plus d'efficacité,
bon, l'informatique, l'élogistique, ça sert à aider les gens à résoudre un problème, disons.
Donc déjà, il faut comprendre le problème.
Ça paraît, il n'a pas lissé ça, ça paraît évident, c'est-à-dire ça,
mais j'ai vu trop souvent des équipes ou des projets démarrer avec une stack techno,
ça chante exactement quelle base de données ils allaient prendre, quelle stack techno,
quel machin, avant même de savoir quel était le problème.
C'est pour ça que mon blase sur Twitter, c'est Yusuke Sviven,
ça fait des années que je suis attaché à ça, c'est que l'espace du problème pour moi,
c'est une de mes obsessions.
Je veux m'assurer, avant de commencer à coder la moine ligne de code,
que j'ai bien compris quel était le problème.
Une fois qu'on a compris quel est le problème, il faut, pour être efficace,
il faut essayer de coller le plus possible à ce non-métier à besoin.
Si par exemple, tu es sur le route et que ce non-métier à besoin de ton métier,
c'est à 2 km à droite, et que toi tu roules sur la gauche et que tu prends un chemin
de travers à gauche, tu vas être déjà mal barré.
Si le client va aller encore plus loin d'un droit à l'est,
toi tu vas devoir réduire ton écart et tu vas rammer le DDD et il dit,
colle le plus près possible du problème par ton code,
par toute la solution que tu vas faire,
essaie de coller le plus possible pour que si il faut aller à droite tout d'un coup,
ou il faut aller à gauche tout d'un coup, tu vas être capable de suivre et de très actif.
Donc c'est vraiment un alignement de ton code, de ta solution, de ton logiciel,
par rapport au besoin, et pour ça il y a plein de façons de faire,
mais c'est déjà un état d'esprit, pour être efficace.
Et puis aussi, pour sortir de ta cave,
moi je sais que au début de ma carrière, on était souvent un peu cachés des dons d'ordre
et puis des gens du métier, je trouve ça vachement plus épanouissant de mon point de vue,
d'aller discuter avec des gens divers et variés qui vont raconter leur métier,
ça me passent toujours.
La techno, j'adore, j'adore ça vraiment,
mais au bout d'un moment, quand tu restes que en vasclos,
moi ça me frustre un peu.
Donc c'est l'occasion d'aller prendre un peu l'air et discuter avec d'autres gens.
Du coup, quand tu parles de coller au plus près du métier,
je crois qu'il y a ce concept d'ubiquitus language,
qui est un peu un espèce de fer de lance, du DDD, ou en tout cas un truc qui revient rapidement.
J'en entends même qu'il réduise presque, ou qu'il le résume à ça.
Du coup, tu vas peut-être pouvoir m'aider à répondre à une question,
mais avant ça, est-ce que tu peux nous préciser ce qui est pour toi l'ubiquitus language ?
L'ubiquitus language, c'est un terme utilisé par Eric Evans,
on traduit ça par « langage omniprésent ».
C'est quoi ? C'est une décision dans la stratégie du DDD de prendre le langage du métier
et de le mettre partout.
D'ailleurs plutôt que d'avoir un langage très IT, très tech dans notre code,
c'est d'employer les mots du métier partout,
que ce soit dans la base de données, dans notre code, dans les interfaces, dans les DTO,
enfin dans tout ce que tu fais, c'est vraiment emprunter les mots du métier.
Tu vois bien, je ne sais pas si toi tu as déjà travaillé sur un projet,
ou entre ce que les gens te disent, le métier te dit, est-ce que tu es dans le code,
c'est complètement différent.
J'avoue pas trop dans les projets que je mène parce que j'essaye de coller.
Par contre, quand je lis les principes du wikutus language,
ou un client doit être capable de lire le code et de comprendre ce qu'il fait,
là par contre je ne suis pas, parce que justement,
j'utilise des termes, soit des termes techniques, soit des termes,
et ça c'était justement la question que j'avais pour toi,
dans la bataille entre le langage français ou anglais.
Pendant longtemps, j'ai été du camp de tout écrire en anglais, anglophone pur,
jusqu'au jour où je réalise, où je me dis que quand même,
il y a des moments où on est tous entre francophones,
il n'y a aucune perspective de voir le code déporté dans un environnement anglophone.
Est-ce que c'est pas un peu débile et contre-productif,
premier point tu vas m'en donner.
Donc déjà, les scénarios, tout ce qui est BDD,
moi j'ai viré pour les écrire en français.
Et là maintenant, je suis même en train de me poser la question du code,
qui était pour moi une espèce de tabou jusqu'à maintenant,
où le code c'est anglais parce que tu as des hyphes qui sont en anglais,
et puis c'est comme ça, c'est la vie, on a perdu, on a perdu.
Mais quand tu tapes sur du métier qui est vraiment spécifique,
en ce moment je bosse dans le médical français et le tout le suivi de remboursement,
c'est même pas que je ne peux pas les traduire,
c'est que les concepts n'existent pas dans notre langue.
On se retrouve entre développeurs, à jongler sur des concerts
qu'on s'est forcé à traduire de manière extrêmement artificielle en anglais,
et à s'y perdre nous-mêmes.
Et là je me dis, est-ce qu'il n'y a pas un problème ?
Mais alors pourquoi ?
C'est ici je pense, mais pourquoi tu l'as traduit en anglais,
c'est là où je n'ai pas bien compris.
Pourquoi vous êtes forcé à tout traduire en anglais ?
Parce qu'il y a cette idée d'avoir un code qui soit toujours écrit en anglais,
qui est une certaine cohérence,
parce que l'offre anglais dans le code,
j'en ai vécu ça au début de ma carrière,
c'est vraiment pénible je trouve aussi.
Donc tu vois, comment trouver l'équilibre entre les deux ?
Est-ce que toi tu codes en français, en anglais, que les termes métier,
tout, comment tu fais ça ?
Tes méthodes, que les autres objets ?
Je vais te faire une réponse qui va peut-être pas te plaire,
ça dépend du contexte.
Donc qui est une réponse qu'on aime bien en délivre en général aussi.
Non mais en fait ça va dépendre.
Effectivement, si le client est français,
qui ne fait que communiquer en français,
que tous les utilisateurs et les utilisateurs sont en français,
moi je vais coller le langage de mon y est présent,
je ne vais pas m'obéter, je vais le faire en français.
Alors bien souvent, quand on code dans les différents langages,
c'est quand même des termes une logis anglaise.
Donc ça peut être le plus possible en français,
et puis le reste ce sera de l'anglais,
mais parce que c'est l'idiôme du Java, du C-Sharp qui va vouloir ça.
Mais le plus possible en français.
Après, il m'est arrivé souvent de bosser sur des projets
où on va faire appel à d'autres gens,
des devs notamment qui viennent de CERBI,
enfin d'autres pays en gros, du Maghrem.
Et donc dans ces cas-là, un besoin d'internationaliser.
Si c'est le cas, dans la mesure du possible,
moi j'aimerais bien qu'on passe tout sans anglais,
parce que ça simplifie la vie.
Il m'est arrivé sur un projet de faire du code en anglais,
mais avec certains mots qui n'étaient pas traductibles, etc.,
traduisibles en français, mais c'était assez rare.
Donc c'est adapté au contexte.
Voilà, si tout le monde parle anglais, enfin en anglais,
si tout le monde parle français, enfin en français,
et si il y a un doute ou si c'est un mix,
bah du coup on favorise l'anglais.
Et du coup, le DDD, quand est-ce qu'il ne te paraît pas pertinent d'en faire ?
Quand est-ce que c'est une approche qui ne te paraît pas adapté ?
Alors, moi ça me paraît toujours pertinent d'en faire,
ne serait-ce que pour le début, c'est-à-dire pour analyser l'espace du problème.
C'est-à-dire avant de savoir ce qu'il faut faire,
d'avoir bien compris le problème, voilà.
Donc de se poser les questions,
au DDD il y a un truc important qui est ton corps domaine.
Donc en gros, tu vas essayer d'identifier quelques contextes,
quelques parties, on va dire, de l'espace du problème,
et tu vas dire voilà, notre valeur ajoutée,
c'est ce qui va nous rendre compétitif par rapport au reste du marché, etc.,
ça va être cette partie-là.
Donc ça, c'est ce qu'on appelle le corps domaine.
Mais pour faire fonctionner la machine,
parfois tu as besoin d'autres éléments.
Tu as besoin de la comptabilité, tu as besoin de, je sais pas, d'autres contextes.
Et dans ce cas-là, tu vas dire, ça va être des domaines de support par exemple.
Donc déjà, ne serait-ce que pour faire l'analyse de ce qu'on me demande de faire,
est-ce que c'est corps domaine ou pas,
est-ce que c'est un domaine support, est-ce que ça est un domaine important,
ça déjà tu vas faire un peu de DDD.
Après, si tu te rends compte que ce qu'on te demande de faire,
c'est du corps domaine, là je vais dire DDD à fond.
Je ne vais pas hésiter à utiliser la boîte à outils.
Si c'est un domaine support, là je vais me poser la question,
est-ce que c'est vraiment un développement spécifique dont vous avez besoin
et pas un projet de ciel ou un produit du marché ?
Et puis voilà, et ou dans certains cas,
si pour des raisons, je ne sais pas, financières économiques ou culturelles,
au lieu de prendre un produit du marché,
il te demande de connaître un logiciel support,
une fonction support,
là tu vas t'autoriser à faire du crûne parfois,
tu vas t'autoriser à faire des trucs qui n'auraient pas de sens
si tu travaillais sur le corps domaine.
Donc encore une fois, ça va dépendre du contexte,
mais ne serait-ce que pour analyser une situation de départ,
toujours utiliser la boîte à outils d'EDD pour se poser quelques questions.
Et bien, écoute Thomas, je te remercie,
je te propose que ce soit le mot de la fin.
Si les auditeurs veulent te suivre,
notamment sur Twitter, ils peuvent venir suivre KALPSEDO.
Ah, use case driven.
Use case driven.

Ce n'est pas mon onduleur, mais c'est le nom.
Je te remercie, Thomas.
Sans prêts.
Merci à moi.
Quant à toi, chers auditeurs, j'espère que tu as apprécié ce podcast.
Si c'est le cas, je t'invite à nous rejoindre dans la communauté des artisans développeurs
sur artisanddeveloppeurs.fr.
Je te dis à demain.