Conférence Devoxx France

Thomas Pierrain et moi avons été très heureux de faire cette conférence à Devoxx France en avril dernier visant à expliquer simplement aux développeurs les nombreux bénéfices de l’approche Domain-Driven-Design. Donc, sans plus attendre la vidéo :

Transcription

Et – cerise sur le gateau – voici la transcription de notre talk :

Thomas Bienvenue à toutes et à tous pour cette session sur le DDD. Petite question rapide : qui sait ce que c’est le DDD ? Ah la vache ! ok

Jérémie Qui est capable de le décrire en 30 secondes ?

Thomas Avant qu’on se présente, on a un bouquin à faire gagner. Donc, en fait, on va faire gagner ça à celui qui aura le plus de retweet sur son tweet par rapport à notre truc. On a un huissier au premier rang dont je garantie l’intégrité

Jérémie La complète indépendance, l’intégrité

Thomas Donc c’est lui qui va compter tout ça. N’hésitez pas à tweeter avec les hashtags de dddreboot. Bon on va se présenter : Thomas Pierrain, architecte technique Je suis curieux et j’aime bien comprendre ce que je fais donc que ce soit à creuser sur des aspects très technologiques Low Latency etc ou très métier

Jérémie Et moi, Jérémie Grodziski, consultant architecte. Je suis très curieux également et j’essaye justement de construire des logiciels de manière simple, pragmatique et efficace et je suis un grand promoteur du DDD depuis très longtemps.

Thomas

Donc avant de commencer je voudrais vous faire une petite confession: quand le DDD est sorti, moi je suis passé complètement à côté. Honnêtement, quand c’est sorti, je n’ai pas lu le bouquin original. j’ai entendu parler des gens du sujet et je me suis dit, tiens ça c’est encore un truc pour consultants qui se sont fait une patternite aigüe, trop de Fowler, trop de patterns et qui ne savent plus quoi vendre à leurs clients.

Bon il faut dire que dans les projets sur lesquels j’avais travaillés, il y avait très peu de… on arrivait pas à séparer la logique métier de la partie technique. A chaque fois on essayait de le faire et puis on se retrouvait avec un accès de données en mode lazy qui finalement nous foutait de la technique dans le métier, enfin c’était le bordel. Je pensais que c’était un mythe et honnêtement je n’y croyais pas.

Et puis, quelques années après j’ai croisé des gens, Cyril Martraire, je ne sais pas s'il est là mais en gros, avec qui on bossait et il parlait tout le temps du DDD, DDD, DDD. En plus, il n’était pas tout seul et c’est là où je me suis dit « j’ai du passer à côté d’un truc » et c’est à ce moment là où j’ai lu le Blue Book d’Eric Evans.

Thomas Et là j’ai pris une claque! Alors le Bluebook ça se mérite. C’est un truc, c’est un sacré pavé ! A chaque fois qu’on le lit on en tire des choses différentes, voila, gros succès d’estime auprès de nombreuses communautés. Le Bluebook et le DDD ça fait très longtemps. Gros succès d’estime auprès de tout un tas d’experts mais honnêtement sur le terrain, je ne sais pas pour vous mais moi…

Thomas ceux qui font du DDD au boulot… Qui fait du DDD au boulot ?

Jérémie Qui fait du DDD au boulot ? de manière quotidienne ?

Thomas de manière quotidienne ? Bon, voilà, ya’ plus personne. En fait, il doit bien y avoir une raison quelque part. Est ce que c’est le DDD qui intrinsèquement est compliqué ? ou est ce que c’est la façon de l’expliquer qui le rend peut être un peu inaccessible ?

Pour ceux qui ne connaissent pas le DDD, y’en a très peu dans la salle c’est dommage mais si je vous dit tactical pattern, bounded context, ubiquitous language est ce que intuitivement déjà comme ça ça vous parle, ça vous . Y’a quelques têtes qui font …..

Honnêtement Kamoulox ?? Pour la première lecture, la première fois dont on entend parler de ces termes, c’est un peu compliqué.

Alors qu’en fait, franchement, le DDD « C’est simple ! » Alors… on pouvait pas vous laisser partir en weekend sans un petit truc à la con qui tourne dans votre cerveau comme ça. Moi je le trouve insupportable ce gamin mais voilà. Alors Jérémie, le Domaine Driven Design c’est…

Jérémie En fait, Le DDD c’est simple.

Jérémie C’est surtout se concentrer sur la valeur métier. Et c’est surtout mettre la valeur métier devant la technologie. Voilà, c’est faire passer la valeur produite par le logiciel avant la technique.

Jérémie En fait j’ai coutume de dire sur tous les projets sur lesquels j’interviens que le premier boulot du développeur justement ce n’est pas de coder, mais c’est d’abord de comprendre le domaine qu’il va coder.

Thomas C’est aussi coder mais pas que !

Alors justement, qu’est ce que le domaine ? Voilà une définition : c’est un ensemble de concepts, alors concepts c’est quoi ? et bien c’est les mots et les définitions qu’on va leur associer. Alors surtout qui vont être employés dans des usages, qui vont être utilisés, donc qui vont être employés à travers des cas d’usage et surtout qui vont permettre de résoudre des problèmes.

Jérémie Ça c’est vraiment important

Thomas On prend un petit exemple.

Jérémie Petit exemple justement de domaine un peu classique en informatique de gestion: la comptabilité en partie double. Les concepts qu’on va trouver ben c’est la notion de compte, la notion de crédit, de débit, de montant etc.

Thomas Les problèmes qu’on résout c’est la traçabilité

Jérémie Oui, ce qui est important c’est pourquoi ces concepts là ont été inventés dans le métier ? et bien juste pour résoudre des problèmes de traçabilité, de fiabilité. C’est à dire qu’on dépense le même montant à travers deux comptes, avec un débit et un crédit. De pouvoir tracer justement les dépenses, d’avoir une garantie de fiabilité qu’il n’y ait pas des dépenses qui n’aient pas été créditées d’abord.

Thomas On va prendre un domaine qui vous parlera un petit peu plus parce que c’est nous les experts de ces domaines là. Le domaine IDE Les concepts c’est : projet, refactoring, analyse de code, debugger etc et les problèmes résolus, plus ou moins bien en fonction des offres, c’est les problèmes de productivité et d’intégration. Donc là nous sommes, les développeurs, les experts du domaine en ce qui concerne ce truc là et ceux qui développent des IDE, les JetBrains et Cie et bien ce sont ceux qui vont développer du soft autour de ce domaine.

Thomas Alors DDD c’est mettre de la valeur métier dans le code mais c’est surtout…

Jérémie C’est surtout une super boite à outils en fait. Ce qui est intéressant avec cette boite à outils, c’est qu’elle est agnostique de la technologie. Cette boite à outils elle est surtout garantie à vie. C’est ça qu’on trouve intéressant c’est que justement le dernier framework JS à la mode ne va pas la démoder, ne va pas la modifier. Donc cette boite à outils elle est très pérenne.

Thomas Ce sont des trucs qui vont durer longtemps.

Thomas Alors… surtout que c’est une tentative d’essayer de vous faire découvrir le DDD, en se mettant… dans une perspective de : quels sont nos problèmes, nous développeurs, au quotidien? et voir qu’est ce qu’il y a dans cette boite à outils du DDD qui peut nous aider à résoudre ces problèmes. Donc on va pas le faire “by the Bluebook”.

Jérémie On va essayer justement de vous montrer quels sont le problèmes auxquels nous, développeurs ou alors praticiens, nous sommes confrontés de manière quotidienne et alors pour cela on va vous proposer trois niveaux :

Thomas 3 Niveaux : on va commencer par parler de code, le binôme

Jérémie Le pair

Thomas Ca c’est le premier niveau de type de problèmes qu’on va rencontrer.

Thomas On va voir ensemble des problèmes qu’on va rencontrer au niveau de l’appli, au niveau de l’équipe, l’architecture de l’application et puis quand on travaille au niveau d’une équipe.

Thomas Et puis des problèmes un peu plus haut niveau, au niveau d’un SI d’une entreprise quand on a plusieurs équipes qui doivent collaborer ensemble. C’est bon pour vous ?

Thomas OK, niveau 1 : le code Alors, on va vous laisser 20 secondes

Jérémie Top chrono

Thomas Pour essayer de comprendre le code qu’on va vous afficher. on voulait vous laisse 20s et on vous écoute après

Jérémie Allez-y

Thomas Alors, des idées ?

Jérémie Est-ce qu’une personne a déjà rencontrée ce genre de code sur un de ses projets ?

Thomas Ouais, y’a du monde, 70% au moins

Jérémie Des idées ?

Thomas Ouais allez les idées, y’a deux trois mots que j’ai entendus là Frais d’expédition ? ouais pas mal ok on va voir ça ensemble en détails. Mais avant de regarder la partie sens et logique, on va voir avec Jérémie ce que ça fait, on va quand même regarder quelques codes smell.

Thomas Alors les codes smell. Vous savez c’est quand on regarde le code on se dit, hum ces petits truc. ça sent pas bon . J’aimerai bien le refactorer un peu. là c’est pas terrible

Thomas Donc on va quand même analyser ce bout de code en regardant les codes smell.

Thomas Alors premier code smell: magic numbers Les magic numbers , ceux qui sont au fond, qui voient pas très bien, ce sont ces chiffres et valeurs numériques qu’on trouve dans le code mais sans aucun sens. Y’a pas de commentaire non plus mais voilà bon. Ce sont des valeurs numériques disséminées à droite à gauche dans le code. Donc ça ça ne porte pas beaucoup de sens.

Jérémie UN deuxième code smell en fait c’est la duplication de code. On voit que là y’a une boucle qui boucle sur les mêmes éléments, qui fait également un test donc on peut se dire ça y’aurait moyen de justement extraire une

Thomas une méthode

Jérémie une méthode de ce truc là.

Thomas Ouais tout à fait. Alors Un troisième code smell c’est les primitive obsessions. Je ne sais pas si vous voyez mais y’a des BigDecimal partout! Quasiment toutes les deux lignes on utilise un BigDecimal. Alors, bon BigDecimal ça peut être pratique mais ça n’apporte pas beaucoup d’informations par exemple…

Jérémie Alors en fait, dans la culture du développeur Java, dès qu’on voit un BigDecimal on se dit Montant parce qu’on sait qu’il va y avoir une histoire d’arrondis, qu’on utilise les BigDecimal pour les arrondis etc. Bref, c’est l’idiome Java mais en tout cas c’est pas explicite.

Thomas Et si c’est un montant est ce qu’il y a une devise associée à ça ? enfin… voilà, tout ca BigDecimal ça n’apporte pas beaucoup d’informations.

Jérémie Donc ensuite on va avoir des… des responsabilités, des préoccupations qui sont un peu mélangées, des exceptions qui remontent. bref, y’ un mélange de techniques

Thomas Y’a du contrôleur…

Jérémie des contrôleurs, y’a un mélange de technique et de métier

Thomas Et enfin, un peu de terminologie, un peu foireuse. Là y’a du CardBean

Jérémie On aime bien les EJB mais bon :-)

Thomas ouais enfin bof On a “i” pour item, c’est peut être plus lisible bon bref. Vous voyez on a déjà un certain nombre de code smell dans ce genre de code.

Thomas Alors maintenant, si on regarde au niveau métier, au niveau sens. On a déjà commencé à vous solliciter tout à l’heure

Jérémie C’est ça, c’est là ou ça va devenir intéressant. On va essayer de chercher tous les implicites. En gros, qu’est ce que peut bien faire ce code?

Jérémie Donc déjà on va regarder ce truc là: CardBean, le total du panier est inférieur à 100. Alors on peut se dire : le total de quoi d’ailleurs. Est ce que c’est le total des éléments dans le panier ? est ce que c’est le prix total ? Inférieur à 100. 100 quoi ? bon ok C’est peut être 100 euros, des brouzoufs, des dollars, des trucs.

Jérémie Ensuite, on a un truc qui est exécuté à chaque fois, est ce que c’est le coût fixe de la livraison ? peut-être mais en tout cas, c’est un coût mais bof on ne sait pas trop ce que ça peut être. On peut… on a un ensemble d’hypothèses ici.

Jérémie Ensuite, pareil, ce que disait Thomas, le BigDecimal donc la devise c’est quoi ? c’est complètement implicite, on bosse qu’en Europe donc c’est que des euros ? ou pas ?

Jérémie Ensuite ici j’ai le poids que je divise par 1000. Bon comme je suis pas complètement idiot, je me dis, tiens c’est peut être des grammes que je transforme en kilo, machin, et ensuite des kilos qui sont utilisés pour calculer le cout variable pour chaque colis expédié.

Jérémie Ensuite, est ce que c’est une option de livraison ? Ensuite, est ce que j’ai un cout variable par catégorie de produits ? Bref, vous voyez le nombre d’implicites qui se trouvent dans ce petit bout de code.

Thomas Tout petit bout de code

Jérémie Ben on peut prendre les listes de questions et on va voir notre expert du domaine ben finalement tout ces machins là c’est vraiment ce que ça doit faire ? C’est ça toute cette logique métier ?

Thomas On a peu de lignes de codes mais on a beaucoup de questions déjà.

Donc une des leçons du DDD c’est d’expliciter les implicites. C’est quelque chose qu’on va répéter plusieurs fois ce soir, avant le weekend, c’est d’expliciter les implicites ! c’est vraiment clé pour lever toutes les ambiguïtés parce qu’on va voir que ça peut poser des petits soucis. Tu nous montrerais pas une version un peu DDD pour comparer ?

Jérémie Ben justement, de manière très concrète maintenant, le DDD, je suis devant ce bout de code, qu’est ce que je vais pouvoir bien faire, qu’est ce que je vais pouvoir refactorer ?

Jérémie Premier point : ça va être de donner du sens, en DDD on appelle ça Intention Revealing Interface. On va prendre une interface, on a la signature de notre méthode, on va tenter de lui donner du sens. Quelle est l’intention qui est derrière ça ? Donc effectivement, ça va être de calculer les coûts de livraison. Pour ça j’ai besoin de deux arguments, le panier et l’option qui a été choisie.

Thomas et ça ne retourne pas un BigDecimal alors?

Jérémie Et ça retourne pas à Bigdecimal, ça retourne un montant. Voilà c’est … Juste avec cette signature on sait déjà ce que fait cette méthode, cette opération.

Maintenant si on reprend le premier test qui a été fait dans ce code, donc on a effectivement le panier, déjà on a précisé ce qu’est le total et bien c’est le prix, c’est le prix total qui doit être inférieur au seuil pour la livraison gratuite

Thomas Qui n’est pas en plus un “magic number” du coup

Jérémie c’est ca. Ce que vous pouvez remarquer ici c’est la manière dont je l’exprime, en langage naturel là en français ou en anglais, en fait je peux quasiment lire la ligne de code. C’est ça qu’on essaye de faire c’est de donner du sens et qu’on ait juste à lire. C’est un peu de la programmation littérale. C’est qu’on ait juste à lire pour comprendre.

Thomas Ca forme comme une DSL. Effectivement quand on a une discussion avec quelqu’un du métier, on peut normalement perdre moins de temps de traduction.

Jérémie Voilà donc ensuite on a le coût par livraison, qui dépend du max de toutes les catégories de produit

Jérémie On a la boucle, bon on passe rapidement là dessus c’est pas ça le plus important

Thomas Ca donne ça quoi

Jérémie voila, ce qui est important en fait c’est de voir que déjà c’est un peu plus succinct et surtout – ça c’est un point que beaucoup de praticiens du DDD font comme retour – c’est que vous prenez un expert du domaine, vous le mettez à côté de vous, vous le laissez regarder votre code et en fait il est capable de comprendre le sens du code que vous lui montrez parce qu’en fait il n’y a aucun mélange avec la technique, enfin vous voyez, y’a que des éléments métier pour le coup.

Thomas Au pire, s’il est un peu allergique au, à l’écran et au code,

Jérémie à la syntaxe

Thomas on peut lire sans avoir à traduire mentalement trop quand on lui parle pour vérifier certaines choses.

Thomas Alors, dans ce ce petit bout de code, y’a un truc qui s’appelle “amount”, le montant, et en fait, ça c’est ce qu’on appelle un Value Type. Là c’est ce qu’on retourne à l’issue de cette fonction. On a un ShippingCost qu’on obtient et puis c’est ça qu’on va retourner et d’ailleurs on va ajouter des montants à d’autres montants. On va voir ça plus en détail après. Alors, c’est quoi un Value Type ?

Thomas Un Value Type ça va pouvoir vous permettre d’exprimer votre domaine mais aussi d’avaler une grosse partie de la complexité dans votre code.

Thomas Un Value Type c’est ce qu’ils sont qui compte, pas qui ils sont.

Thomas Donc on va le voir dans un Value Type, c’est la somme de ses attributs, c’est ça qui va constituer et donner le sens au Value Type, pas son identité.

Thomas Par exemple, je sais pas, Jérémie, t’as pas 10€ ? STP ?

Jérémie heu si

Thomas Voila

Jérémie Qu’est ce que tu veux faire ?

Thomas Ben ça c’est 10€. Ben merci! et puis …

Jérémie Bon je me suis fait gratter 10€

Thomas Non non, t’inquiète t’inquiète, voilà un beau billet donc en fait, on peut échanger, les deux billets sont équivalents

Jérémie Il est un peu zarbi ton billet quand même

Thomas Ouais, c’est mon fils qui a du jouer avec… Non mais les billets… Ce qui est important c’est la valeur pas les identités. Alors sauf, si mon domaine : je suis banque de France ou banque fédérale et mon domaine c’est de suivre la traçabilité des billets. Dans ce cas là, les 10€ ne sont plus un Value Type mais c’est une entité, quelque chose dont je vais vouloir suivre l’identité à travers le temps.

Jérémie parce qu’il y a un numéro dessus

Thomas Parce qu’il y a un numéro dessus, Mon domaine c’est ça

Thomas Alors Value Type, d’autres exemples : Nombre 42, la couleur jaune qui est une association de RVB, une vitesse de 50 km/h, un billet de 10€ dont on vient de vous parler sont quelques exemples mais il y en a plein.

Jérémie Effectivement l’usage du billet n’est pas modifié parce que c’est une valeur. Alors si on regarde justement les caractéristiques du Value Type sur lequel on va zoommer derrière. Par définition c’est immutable. Par définition de ce qu’est une valeur. Surtout c’est pas juste de la donnée en fait, c’est riche en logique du domaine c’est à dire qu’il y a vraiment du comportement il y a des choses qui vont se passer, y’a du code qui va s’exécuter et ce que je vous propose c’est qu’on commence à regarder toutes les caractéristiques de cette définition.

Jérémie Donc la première caractéristique c’est celle d’immutabilité, par définition, une valeur est immutable, ne change pas. Concrètement en terme d’implémentation, ce qu’on va mettre en oeuvre c’est un constructeur dit transactionnel. Ce constructeur en fait va faire un ensemble de validations et soit l’objet est bon, il respecte toutes les contraintes : si je prends un montant, un montant est forcément strictement positif, un montant négatif ça n’existe pas. Donc je vais lever une exception c’est à dire que soit l’objet existe, il est bon, soit il n’est pas bon et il n’existe pas. Donc c’est cette bonne pratique de Fail Fast que vous devez connaitre et toutes ces contraintes sont renforcées par le constructeur, également par les opérations, c’est read only y’a pas de setters

Thomas Il ne faut pas qu’il puisse changer

Jérémie Il est immutable, voilà.

Thomas Un autre élément c’est riche en logique du domaine. Donc en fait déjà on va commencer par nommer les fonctions en utilisant le langage du métier, le langage du domaine. Ca c’est aussi important. Donc c’est … on va le voir un peu plus un détail après

Jérémie Autre point, c’est que le Value Type est complètement défini par l’ensemble de ses attributs. Ce que ça veut dire c’est que l’égalité et son corollaire, l’unicité, sont très forts, ont un sens très fort. Soit tous les attributs participent à l’égalité alors soit c’est un smell c’est à dire que si vous en enlevez un, et bien y’a peut-être une question à se poser ? En tout cas, très concrètement c’est le Equal, c’est le Hashcode actuellement. La mais on est vraiment sur l’ensemble des attributs. c’est extrêmement important.

Thomas Sur le cas du montant si dans le equal j’ai le hashcode qui n’applique pas la devise, tu peux dire que deux montants sont équivalents alors que la devise n’est pas la même donc là c’est…

Jérémie et donc … on peut jamais ajouter effectivement des euros avec des dollars, ça n’a pas de sens

Thomas Donc effectivement tous les attributs sont importants dans l’égalité et l’unicité.

Thomas Puis enfin un point important c’est que ce sont des fonctions combinables que va exposer ce Value Type. Donc au lieu de changer la valeur, et l’état dans un sens comme on faisait avant, avant on avait un objet à l’ancienne on va dire, on avait un amount. On fait un add d’un autre amount et puis ça va modifier l’instance amount. Et bien en fait avec les Value Type, on va composer et on va réaffecter. Donc là, l’opération Add elle porte sur un montant, on lui ajoute un autre montant et le résultat de cette opération me retourne un nouveau montant qu’un nouveau Value Type pardon et donc c’est ça qu’on veut réaffecter et suivre autour de la logique métier

Jérémie Pour ceux qui utilisent des langage fonctionnels, vous avez reconnu effectivement les principes des langages fonctionnels qui diffusent.

Thomas Une partie du Bluebook et du DDD c’est de s’inspirer des paradigmes fonctionnels y compris dans l’orienté objet si vous êtes en Java etc. Ben vous pouvez quand même mettre un peu de fonctionnel dans votre objet.

Thomas Alors le Value Type c’est ce qui va vous permettre d’avaler - j’en vois que ça fait plaisir - d’avaler la complexité essentielle, c’est à dire la complexité de votre métier, de votre domaine. Ca vous permet d’avaler cette complexité mais aussi la complexité accidentelle. Tous les effets de bord liés à des états, d’instance, d’accès concurrent etc. Tout ça va l’absorber.

Jérémie Alors en DDD on appelle ça comment ? On appelle ça un Value Object. Alors pourquoi Value Object et pourquoi on a parlé de Value Type ? C’est que historiquement le DDD est quand même bien ancré dans le paradigme Objet.

Thomas C’était il y a 13 ans donc…

Jérémie C’était il y a 13 ans. En fait, c’est un oxymore et le Value Object est un oxymore, pourquoi ? un objet ça bouge…

Thomas C’est quoi un oxymore ?

Jérémie Un oxymore c’est deux termes qui sont collés l’un à l’autre et qui sont opposés.

Jérémie Par exemple, feu glacé,

Thomas Clarté obscure

Jérémie Voilà en fait, le Value Object c’est un oxymore parce que si c’est une valeur ça ne bouge pas et un objet ça bouge donc on associe les deux. Alors pourquoi ? C’est que historiquement, le Value Object était un moyen d’implémenter le concept de valeur dans un langage impératif objet type Java, C# etc. Maintenant on est 13 ans après, les langages fonctionnels sont donc beaucoup plus répandus donc on parle beaucoup maintenant de Value Type parce que les langages fonctionnels c’est XXX

Thomas C’est plus consistant

Jérémie C’est plus consistant, voila. En tout cas historiquement ça s’appelait comme ça.

Thomas Ouais, alors, Pour Jérémie et moi franchement le Value Type c’est le meilleur ROI du DDD. Honnêtement c’est un ROI incroyable. Alors on va voir pourquoi.

Jérémie Alors pourquoi ce ROI effectivement est imbattable? Déjà, ça introduit en fait le domaine, le langage du domaine dans le code. ça c’est vraiment le point-clé et surtout ça va permettre justement d’introduire de manière progressive ce langage du domaine et surtout ça va permettre de cohabiter avec un code un peu plus legacy. Si vous trouvez encore des BigDecimal et tout ça qui trainent et bien vous pouvez quand même mettre un Amount à coté et surtout vous allez donner l’exemple. C’est à dire que vous allez pouvoir montrer au reste des développeurs, de l’équipe etc. qu’en fait c’est beaucoup plus simple. C’est un avaleur de complexité en fait le Value Type, puisqu’il va prendre tout un tas le logiques métier, le fait que le montant soit toujours strictement positif

Thomas Au lieu d’avoir la logique à droite, à gauche pour la même chose, ça va encapsuler un peut tout ça

Jérémie Ca va encapsuler un peu tout ça. Ça va être beaucoup plus simple à utiliser, ça va simplifier le raisonnement par ce que c’est immutable, parce que c’est Thread-safe etc. donc introduction progressive et donc ça permet de cohabiter. On est pas obligé de tout casser, de dire bon voilà on fait du DDD du jour au lendemain. Vous pouvez commencer sur une petite partie du code.

Jérémie Et… on a quand même introduit le langage du domaine dans le code et je pense que le point clé du Value Type c’est …

Thomas Ca plante un peu la graine du domaine dans le code. Petit à petit c’est un moyen assez efficace pour donner plus de sens dans notre codebase.

Thomas Et encore une fois, c’est l’occasion : On explicite ce qui est implicite, ce qui est ambigu. Donc ça contribue à ça.

Thomas En terme d’explicitation, toi y’a un terme qui te plait bien c’est Data Literal

Jérémie Moi, y’a un truc qui me plait bien. Si on reprend cet exemple là des coûts de livraison. Là on a repris directement le manuel, en fait on va dire l’aide en ligne d’Amazon avec justement les règles qui doivent être implémentées. Les règles d’ailleurs qui sont exposées aux clients sur les coûts de livraison. Vous soyez que là en fait on a une table de décision. Tout simplement.

Jérémie Moi y’a un truc qui me plait bien, c’est qu’on va essayer d’introduire le langage du domaine dans le code c’est à dire sur les opérations. Mais on peut aussi faire pareil sur les structures de données; donc j’ai fait un talk il y a quelques mois là-dessus sur pourquoi les Data Literals à mon sens sont importants et vous voyez qu’en fait, là pareil, on va essayer avec le DDD d’être le plus proche possible du langage de l’expert du domaine, et en gros c’est le même langage que l’utilisateur. Vous voyez, il n’y a quasiment pas de différence entre la structure de données, à la suite du domaine que l’on exprime et le langage du domaine et donc on peut le manipuler. Voilà on a rendu explicite, on a rendu très très proche, la structure de données aussi bien que le code.

Thomas Puisqu’on parle d’implicite, je sais qu’il y a un truc qui te fait plaisir à toi là

Jérémie Alors moi je suis fan de Woody Allen effectivement. Alors Woody Allen, lui en fait quand il entend du Wagner et bien ça lui donne envie d’envahir la Pologne. Petit clin d’oeil à mes origines également :-)

Jérémie Moi effectivement quand je vois un manager dans le code, manager, helper, user, handler…

Jérémie En fait ça me donne envie de les shooter aussi parce que justement c’est complètement implicite. Ca veut tout dire et rien dire un manager. Un helper un machin enfin tout ce qui finit par “ER”. Un user !

Thomas Un user, on est tous utilisateurs

Jérémie On utilise tous des trucs enfin voilà bon Donc, voilà, c’est toujours pareil, c’est rendre explicite ce qui est implicite. C’est donner du sens.

Thomas Alors l’autre type problème : quand on code, on a un peu besoin de savoir ce qu’il faut faire et coder.

Thomas Et je ne sais pas si ça vous est déjà arrivé sur le projet, d’avoir un utilisateur à gauche et vous à droite et entre le besoin initial et vous qui allez le réaliser il y a tout un tas d’intermédiaire.

Thomas Parfois il y a un peu de pertes en ligne. Je ne sais pas si ça vous parle ce genre de situation ? Oui, doucement, ouais. Alors, parfois c’est compliqué d’avoir accès aux utilisateurs, experts du domaine, parfois ils ne veulent pas jouer le jeu aussi, parfois c’est compliqué.

Thomas C’est Alberto Brandolini, qui a crée l’Event Storming, qui a une expression que j’aime bien et qui dit aux gens un peu récalcitrants, aux experts du domaine récalcitrants : ne vous trompez pas, c’est ce que le développeur a dans sa tête qui va partir en prod, c’est pas votre connaissance à vous donc jouez le jeu, c’est ça qui est important.

Thomas Et puis c’est assez fatiguant à la longue, je ne sais pas pour vous mais moi dans ma codebase d’avoir une terminologie particulière et qui ne correspond pas du tout avec ce que nos experts du domaine et nos correspondants métier nous disent, moi ça me fait faire un effort de traduction en permanence, je trouve ça usant. Quand j’ai commencé ma carrière j’ai même un chef de projet qui était venu me dire “mais ça ne parle pas du tout de la même chose, le code, ce que j’avais lu dans un livre la veille ? Non mais t’inquiète les utilisateurs c’est des gros blaireaux, nous on sait mieux qu’eux ce qu’est leur métier.” bon voilà… mais dans tous les cas,

Jérémie Ca parle à certains…:-)

Thomas Oui… dans tous les cas, c’est usant. J’en vois deux trois qui… voilà.

Thomas Dans certains cas…

Jérémie Dans certains cas on arrive même à des fusées qui se crashent tout simplement parce qu’on ne s’est compris sur l’unité métrique qu’il fallait employer et Ariane s’est plantée à cause de ça. C’est à dire qu’on a confondu des pieds et des mètres et manque de bol et bien c’est des types primitifs, on ne sait pas ce qu’il y a dedans.

Thomas Ca devait être un BigDecimal peut être ;-)

Jérémie Ca devait être un BigDecimal voila :-)

Thomas Bon la solution du DDD à cette problématique de parler différentes langues et pas se comprendre, c’est quoi ?

Jérémie La solution du DDD c’est simplement d’utiliser le même langage. Alors ça parait évident, ça parait bête. C’est un langage pour tous les unifier. C’est le langage des utilisateurs en DDD.

Jérémie Ca s’appelle un Ubiquitous Language En français on pourrait dire un langage omniprésent. Alors bon voilà on utilise un seul langage mais bon quand même…

Thomas Un seul langage d’accord mais comment on fait ?

Thomas Y’a certains cas par exemple, un client, en fonction de l’interlocuteur à qui je m’adresse, ça va être “L’homme aux 1000 visages”. Pour certains, un client ça va être le trader et le sales par exemple le contexte pour qui il bosse. Pour d’autres le client ça va être vraiment le client final de la banque. Enfin, voilà.

Thomas Dans la tête de chacun y’a plein d’implicites. Comment on fait en fait ? Un seul langage quand les gens ne parlent pas le même langage.

Jérémie Alors, là pareil, le DDD a une solution. Ça s‘appelle de contextualiser. C’est à dire, en gros, à un même mot de donner un contexte.

Jérémie Alors un contexte… définition, tout bêtement c’est quoi ? Et bien ça va être le sens qui va être donné à un mot suivant le groupe de personnes qui va l’employer. Tout simplement, en gros ben ça va être les êtres humains. Des groupes d’êtres humains qui vont se côtoyer, qui vont parler la même langue et à chaque fois qu’ils vont employer le mot client, en fait, ils vont reconnecter ce mot avec l’ensemble qu’ils ont dans leur tête et pour eux , suivant ces groupes de personnes ce n’est pas forcément la même chose.

Thomas Je propose qu’on prenne un exemple

Jérémie Voilà on va prendre un exemple

Thomas EN DDD un contexte c’est une patate. C’est comme ça qu’on le représente, donc pour le contexte de la CRM, de la vente, un client en fait c’est la catégorie socio-professionnelle du client et ses centres d’intérêt.

Thomas Pour un autre contexte qu’est la comptabilité, le client, tout ce qui l’intéresse c’est ses moyens et ses délais de paiement

Thomas et enfin pour un autre contexte qui serait les commandes et les livraisons, tout ce qui nous intéresse c’est ses adresses et ses disponibilités pour les livraisons. Derrière, tout le monde parle de “Client” mais ce ne sont pas des mêmes usages et on ne parle pas des même choses.

Jérémie EN DDD ça a un nom aussi, ça s’appelle des Bounded Context. Bon ça peut faire peur d’un premier abord : _Contexte Délimité__

Jérémie Et voilà, on va employer un seul modèle, un seul langage en fait dans chaque groupe de personnes.

Thomas Dans chaque contexte effectivement chacun a son langage.

Thomas Dans le même contexte, dans les mêmes frontières tout le monde doit parler le même langage dans le code, avec les utilisateurs et tout mais on en a plusieurs.

Jérémie Alors, ce qui est vraiment important, c’est pas tant les artefact c’est à dire les progiciels, les bases de données, les bases de code qui sont employés, ce sont surtout les groupes de personnes qui vont les utiliser. C’est pas parce que vous utilisez SAP effectivement que c’est pas SAP en soit c’est surtout les groupes de personnes qui vont l’employer, qui ont construit SAP et qui l’utilisent. C’est ça qui est important.

Thomas On prend peut être un exemple concret

Jérémie Alors je pense que tout le monde a déjà vu cette page d’accueil. Tout le monde a déjà passé éventuellement des commandes sur Amazon. En fait, ce qu’on peut regarder très rapidement là-dessus, on peut se mettre à la place de Jeff et se dire “Je vais avoir un ensemble d’équipes qui vont implémenter Amazon.com” et on peut regarder justement quels seraient les contextes ? En fait Amazon c’est quoi ? ça va vendre des produits. Bon ok avec ça on a tout dit et rien dit..

Jérémie Déjà on va avoir le catalogue produits : comment les produits sont structurés ? alimentés ? etc. On a le contexte de la recherche…

Thomas En fait on en a plein En fait, ça correspond à des équipes différentes et des usages différents alors les uns et les autres vont devoir collaborer pour au final avoir ce résultat final mais voilà… l’idée du contexte elle est clé dans le DDD

Jérémie Des équipes qui vont échanger.

Thomas ça c’est un autre points, y’a des modèles etc. Attention par contre de ne pas tomber dans le modélisme. Alors le modélisme c’est quelque chose dont Grégory Weinbach a parlé il y a quelques temps à Devoxx donc il doit être encore disponible en vidéo. Assez exceptionnel, c’est comment il n’y a pas de bon modèle métier.

Thomas Modélisme c’est quoi ? C’est modéliser pour modéliser mais sans usage. On a pas du tout d’usage en tête donc un client c’est la somme de tout ce que je peux imaginer en le mettant sur un papier. C’est la somme de toute les caractéristiques. On fout ça dans un modèle de données, de base de données, et puis à l’application d’aller se démerder dans ce modèle unique pour aller chercher à droite à gauche le modèle qui les intéresse. Ça c’est du modélisme. On est pas avec des usages en tête.

Thomas Vraiment ce qui est important c’est que les modèles servent à des usages. Même une carte. Une carte est faite pour naviguer, elle est faite pour traiter des problèmes géo-politique. Une modélisation c’est pour des usages alors attention de ne pas tomber dans le piège du modélisme ou on perd l’objectif initial. Voilà.

Thomas Bon on a vu au premier niveau hein, deuxième niveau, on va voir d’autres types de problèmes.

Thomas Alors le premier problème

Jérémie Effectivement, là maintenant on est sur une application, on travaille en équipe et bon, ben, on va éviter d’arriver à ça. On va éviter d’arriver au plat de spaghettis. Et bien on va éviter d’avoir des dépendances dans tous les coins. Alors tout ce qui est important c’est que dans le plat de spaghettis il y a surtout les boulettes de viandes, ici ça va être le domaine.

Thomas La valeur métier quoi.

Jérémie La valeur métier qui va être disséminée à droite et a gauche. Alors, on peut mettre en place des architectures en couches, là c’est des lasagnes, là mais même ça on a les boulettes.

Thomas La viande se mélange

Jérémie La viande se mélange quand même, on peut avoir des logique métier dans le contrôleurs. L’objectif ça va être d’essayer de bien séparer tout ça.

Thomas Alors ça me fait penser au mikado parfois.. Dans les applications, on change juste une partie. On se dit tiens, je change juste cette partie technique là et puis ça va marcher et la moitié du soft s’effondre par ce qu’il y a d’autres dépendances etc etc. Donc comment on arrive à bien séparer la logique métier de la logique d’infrastructure et du code technique ? et bien pour ça y’a une solution !

Qui s’appelle l’architecture hexagonale. Alors…

Thomas Architecture hexagonale ça veut dire quoi ? ça veut dire que le monde se divise en 2 catégories : Très simple

Thomas Y’a le dedans et le dehors.

Thomas Le dedans c’est le domaine, c’est la logique métier. Le dehors c’est tout ce qui est Infra (middleware, base de données etc etc.)

Thomas L’archi hexagonale ça veut dire quoi ? ça veut dire mettre des barbelés autour du domaine, de le protéger et de faire en sorte que toute l’infrastruture, le code technique ne s’insère pas dedans, ne rentre pas dedans. Alors pour traverser les barbelés parce qu’on a quand même besoin de s’échanger des informations et bien on va avoir des ports et des adapteurs qui vont nous permettre par relation de dépendances, par tout un tas de mécanismes, l’idée c’est pas de creuser l’archi hexagonale ce soir. C’est de vous dire que ça existe pour ceux qui n’en aurait pas entendu parler encore.

Thomas C’est assez important alors à retenir c’est le dedans et le dehors. y’a que deux zones dans l’archi hexagonale, c’est ça qui est important.

Thomas Alors, je sais que hier il y a Samuel Brown qui a parlé de l’architecture hexagonale et de layers et qui aurait dit que c’était la même chose. Moi je n’y étais pas, on m’a raconté ça.

Jérémie On est pas d’accord :-)

Thomas oui on est pas super d’accord. Heu… donc l’architecture. L’architecture en couche et bien ça va être présenté un peu comme ça

Thomas Alors que l’architecture hexagonale, en fait c’est 2 zones. On a que du domaine en bas et puis on va avoir différents ports et adapteurs et tous les éléments d’infrastructure vont être positionné à la même enseigne. Y’a pas de hauteur, de machin, de dépendance, y’ que deux couches en fait. Y’a le dedans et le dehors et dans une des couches du dehors on peut sharder, on peut répartir. Donc on va considérer que la base de données ou le middleware ou les API pour interroger notre système ou une SPI pour aller rechercher des informations à côté, sont logés à la même enseigne.

Thomas Alors y’a quelqu’un qui nous a dit (c’est dommage on voit pas) l’architecture hexagonale c’est OUF comme ce pattern peut changer nos vies. Alors je ne suis pas sur que ce soit lui! (super, merci) mais c’est vrai !

Jérémie Alors y’a un autre problème aussi

Jérémie C’est que on peut arriver dans un bourbier aussi, le bourbier du legacy. Attends tu as changé les Slides ?

Thomas On avait dit qu’on parlait du bourbier du Vietnam

Jérémie Attends mais c’est pas celles là

Thomas Tu veux un peu plus. C’est la guerre. Ouais le Vietnam.

Jérémie Ouais mais moi j’aime bien l’odeur du Napalm le matin..

Jérémie Ah voilà Wagner !

Thomas Parfois le legacy c’est ça. faut y aller.

Jérémie C’est retrousser ses manches

Thomas C’est pas toujours beau beau beau mais bon.

Thomas On a une question récurrente quand même quand on est face à du legacy : on refait tout ou pas ?

Thomas Le DDD propose plusieurs options, plusieurs réflexions, alors on va en prendre une : le contexte d’une application legacy avec ses contours plus ou moins bien dessinés.

Thomas Donc à l’intérieur de ce contexte legacy on peut néanmoins faire ce qu’on appelle un Bubble Context, un contexte ou là ça va être clean, ça va être développé en mode DDD avec des Value Types. On va pouvoir faire du DDD enfin voila, et en fait pour se protéger, on va traduire, on va traverser.

Thomas On va éviter que le code legacy ne s’insère dans cette alvéole de DDD par un Anti Corruption Layer c’est pareil c’est une sorte d’adaptateur. Alors ça c’est Cyril Martraire qui a fait un talk qui est génial là dessus il y a quelques année à Londres. Il doit être encore disponible, on mettra les liens à la fin qui en parlent très très bien avec un retour d’expérience, franchement je vous le recommande.

Thomas Alors maintenant on va se mettre au niveau sérieux quoi, au niveau de l’entreprise. Quel type de problème on rencontre ?

Jérémie Alors voilà. On est maintenant dans le cadre de n’importe quel système d’entreprise, on est dans un système d’informations, on est plusieurs équipes et il va falloir communiquer. Alors il va falloir communiquer effectivement et faire communiquer nos systèmes techniques mais surtout il va falloir communiquer entre nous de manière humaine et ben là c’est.

Thomas Ca vous est déjà arrivé de dépendre d’une autre équipe qui délivrait une API dont on a besoin et cette autre équipe change le contrat un peu comme ça l’arrange sans vous prévenir etc. Ca vous est déjà arrivé ou pas ?

Thomas On a l’impression d’être cette petite voiture noire, tranquille, on est en train de bosser et tout d’un coup ils changent un truc là le camion et on se retrouve un peu embarqué sans le vouloir quoi. Voilà, alors on a beau crier mais c’est pas une espace. Dans la petite voiture, personne ne nous entends crier quoi, on subit un peu le truc.

Jérémie Alors en fait et bien justement quand on est dans une entreprise et bien voilà malheureusement il y a des relations de pouvoir qui sont là

Thomas AH bon ? Il y a de la politique dans l’entreprise ?

Jérémie Ouais y’a de la politique dans l’entreprise :-)

Thomas Ah merde !

Jérémie Et que effectivement comme y’a des groupes d’être humaines et bien pareil il faut expliciter ces relations de pouvoir, ces implicites. C’est pas juste des systèmes techniques. Vous vous souvenez de la loi de Conway ? et bien ça s’applique en plein c’est à dire qu’on va essayer d’expliciter les rapports de communications, de pouvoir, qu’il va y avoir entre les équipes, avant la technique.

Jérémie Et pour ça en fait, le DDD va vous proposer une métaphore qui est assez simple et efficace, c’est la métaphore du courant et de la rivière. C’est à dire que si vous êtes en amont et si vous pissez dans la rivière, les gens qui sont en aval vont être impactés. Donc c’est cet amont, cet aval. Ca permet de voir comment 2 systèmes, 2 équipes vont communiquer. C’est à dire que s’il y en a un qui fait un truc et bien qui est impacté ?

Jérémie Vous vous souvenez le camion et la voiture et…

Thomas On va illustrer ça. Ca s’appelle un context map en DDD. Alors là on a ce catalogue produit tout en haut. Il est en haut de la rivière et puis il y a un contexte les équipes chez Amazon qui s’occupent du “Search” qui dépendent du catalogue produits quelque part.

donc ce qui est upstream c’est le catalogue produit et ce qui est downstream c’est le contexte du “Search”. Donc on peut réduire ça un peu, encore une fois si je suis dans les équipes du contexte “Search”, j’ai peut-être envie de me protéger des changements intempestifs du catalogue produits parce que si j’ai des dépendances vers des informations du catalogue produit un peu partout et bien mes éléments du contexte de recherche quand ça change, je vais le sentir passer.

Alors là. un peu de protection, un peu de _Anti Corruption Layer, c’est un des patterns, y’en a plein d’autres dans le DDD.

Jérémie Parce que là, l’implicite, explicite plutôt c’est de dire que le catalogue produits c’est lui qui a le pouvoir parce que effectivement c’est là qu’est le “nerf de la guerre”, et le “Search” c’est plus secondaire, donc moins de pouvoir, ça veut dire qu’ils subissent un peu tout ce que fait le catalogue produit.

Thomas Dans le DDD, ca vaudrait un talk à part entière sur cette partie là, y’a plein de patterns, on les a pas tous listés mais c’est important de savoir qu’ils existent

Thomas Parce que ça vaut la peine de survivre dans le monde pas si bisounours que ça des entreprises.

Thomas Alors en DDD

Jérémie Justement c’est la Context Map et le Strategic Design. Il y a tout un tas de sujets.

Thomas C’est très riche. Le DDD ça a de gros apports.

Jérémie Un point : c’est que c’est vraiment l’innovation du DDD. On peut dire que le DDD en fait c’est de l’orienté objet arrivé à maturité, c’est 20 ans d’expérience sur l’objet. Par contre, la vraie innovation du DDD c’est celle là : le strategic design.

Thomas Bon, on a bientôt fini, avant de se quitter, et de passer un bon weekend

Thomas On peut dire que le Domain Driven Design c’est se concentrer sur la valeur métier. Voilà rappelez vous pour le weekend, non c’est beaucoup plus…

Jérémie C’est beaucoup plus accessible et utile qu’il n’y parait et donc

Jérémie Dès lundi, vous pouvez appliquer des principes du DDD

Thomas Un autre objectif serait que vous ayez envie dès lundi d’essayer de se dire “tiens j’ai envie de mettre un peu plus de Value Type dans ma base de code, voir ce que ça donne etc.” c’est assez simple.

Jérémie On vous a présenté, sur plusieurs niveaux, différents concepts du DDD alors c’est très très riche. On vous a présenté ceux que nous estimions importants, en tout cas utiles, avec un très bon retour sur investissement, le Value Type notamment.

Thomas Y’en a d’autres qui sont avec une petite astérisque là, pas directement empruntés au DDD mais ça va bien ensemble, ce sont des concepts qui marchent bien ensemble.

Jérémie Au niveau du DDD, le BBD, Behavior Driven Development, c’est le genre de techniques qui se marient très très bien avec le DDD.

Thomas De distiller le modèle comme on dit etc.

Thomas On a bien conscience qu’on est positionné sur des épaules de géants, Eric Evans notamment et avant lui Eric Evans s’est aussi inspiré de ce qui s’est fait avant.

Thomas Mais parfois c’est un peu intimidant. Quand on lit le bluebook la première fois on se dit WOW, c’est une sacrée oeuvre et donc pour changer et apporter des choses sur ce concept là il va falloir s’accrocher un peu.

Thomas On va remercier Eric

Jérémie Merci Eric! d’avoir introduit tous ces concepts dans la communauté, de nous avoir donné, nous, constructeurs de logiciels, un vocabulaire, de nous avoir donné des concepts, des concepts justement sur lesquels on peut échanger, on peut se comprendre. C’est notre domaine le DDD.

Thomas Oui. Merci Eric mais nous on se propose de redynamiser le sujet parce qu’on pense que trop peu de gens l’utilisent et il y a des pépites

Jérémie On pense que c’est quelque chose qui a énormément de valeur et donc on voudrait qu’il y ait une communauté ouverte de praticiens avec un premier objectif

Thomas Populariser le DDD en le rendant plus accessible. Moi je sais que pour avoir essayé, la première fois que j’ai lu le bluebook, J’ai voulu faire du DDD très rapidement avec les équipes avec lesquelles je bossais etc. Et en fait j’étais trop “by the bluebook” et donc j’utilisais tout le jargon du DDD et franchement ça a été un massacre. Les gens me regardaient et “ouais c’est bien”. Donc en fait, ce qui est plus intéressant quand vous voulez vendre du DDD c’est de le faire,

Jérémie C’est de pas le dire en fait…

Thomas De ne pas le dire et après d’expliquer qu’il y a une grammaire, il y a un jargon, des choses pour que les experts puissent échanger, partager mais c’est pas ça le plus important c’est le “pourquoi ?”” et c’est ce qui est mis en avant

Jérémie Et puis, pour ceux qui sont un peu plus experts là dessus et bien c’est de continuer à étendre la boite à outils. Il y a énormément de sujets à traiter : avec les langages fonctionnels, la technologie “pousse” aussi avec de nouveaux concepts, des langages fonctionnels, les gestions de règles, la conception par rôle etc, DSL, y’a tout un tas de sujets, justement qu’on pourrait voir venir et qui pourraient être utiles pour le boulot

Thomas Donc nous on vous propose de rejoindre cette communauté qu’on voudrait monter à partir d’aujourd’hui. On a créé un compte Twitter qui s’appelle DDDreboot. On a créé un Slack etc.. Via le compte Twitter vous allez avoir toutes les informations pour pouvoir suivre tous ceux qui vont vouloir partager, travailler sur ces sujets là.

Jérémie Et pour la route, le petit take away : Bien sûr, rendre l’explicite implicite et moi je dirais tout est question de langage, en fait, tout est question de mot qu’on va employer, tout est question de sens donc c’est ça en fait le DDD. Et pour conclure…

Thomas Ben c’est mettre du domaine dans le code un peu plus de sens, de valeur dans le code. Il nous reste plus qu’à vous remercier. Peut être qu’il nous reste…. peut être un de temps pour vos questions.

• Il n’y a pas de bon modèle métier (talk de Grégory WEINBACH)
• Monoids, monoids, everywhere! (Cyrille MARTRAIRE)
• Why data literals matter (Jérémie GRODZISKI)
• Applying DDD in a legacy Application (Cyrille MARTRAIRE)
• Coder sans peur du changement avec la 
« même pas mal ! » architecture hexagonale (Cyrille MARTRAIRE & Thomas PIERRAIN)

Thomas On a mis ici une liste de liens, alors y’a du XXX Mais y’a d’autres talks, par exemple le talk de Gregory, il n’y a pas de bon modèle métier que je vous recommande vraiment. Cyril Martraire qui a fait des Monoids avec des verres de bière c’est génial sur l’approche fonctionnelle. y’a le tien, sur les Data Literals. y’a le contexte legacy faire du DDD en legacy de cyril pareil. Tout ça sur Internet, on les mettra. Et l’université, que j’ai eu la chance de faire avec Cyril l’année dernière sur l’archi hexagonale, voilà. Sur les 3 heures vous pouvez ne regarder que la première heure, à mon avis ça suffit. Donc voilà est ce que vous avez des questions ? Ben merci déjà parce que un vendredi avant le weekend Peut-être une petite question: a qui on a donné envie de faire un peu plus de DDD ou de faire un peu de DDD lundi ?

Jérémie Bravo on va passer un bon weekend

Thomas Est ce que vous avez des questions ? il reste 4mn12.

Thomas Pour ceux qui veulent rester, il y a les CastCodeurs qui vont s’installer ici. Tu as une question ? Comment je commence si je veux mettre en place du DDD dans une équipe ?

Jérémie Le plan d’attaque pour effectivement mettre en place du DDD. Alors, effectivement c’est pas simple, mais je pense que le premier point c’est de comprendre le domaine, c’est d’essayer justement de regarder quel est le domaine, de le comprendre. Ce n’est pas forcément d’aller dans le code c’est d’essayer de parler avec les experts du domaine et de voir si la compréhension du domaine est là. Après on pourra arriver dans le code. Après ça dépend de ta sphère d’influence si bien sûr tu n’as pas accès aux experts du domaine ça va être compliqué. Thomas tu as peut être un retour ?

Thomas Et puis c’est de creuser un peu. Les sujets ? Tes utilisateurs ? Ton domaine…

Jérémie Tes usages? Ça peut être des scénarios, faire du BDD par exemple dans un premier temps, après tu pourras basculer sur de la conception en tant que telle. Après ça dépend si tu es sur un système “from Scratch” ou “legacy” bon bref c’est de la réponse de consultant mais en fait ça dépend.

Thomas Mais par contre tu n’es pas obligé de tout faire. Pour moi, c’est à la carte. Tu prends des trucs, ça marche, ça marche pas. Tu prends dans le corpus.

Jérémie T’es pas forcément obligé de le dire par contre. C’est surtout ça notre retour. Faut pas dire que DDD machin.

Thomas Ça fait peur qu’il y ait une image un peu élitiste associée parfois

Jérémie Les termes sont compliqués et puis tout ce langage, Bounding Context ça fait peur.

Thomas La question c’est la question de l’expansion, l’entreprise grandit et ce qui était un simple domaine au départ devient plusieurs domaines, et donc les notions qu’on avait à la base du client, elles peuvent changer. C’est ça ta question ?

Jérémie Mes points que je dirais c’est un peu circonspect parce que la tentation du modele canonique, du modéle unique, faut vraiment s’en méfier. L’autre point c’est l’une des phrases que j’aime bien dire aussi : c’est que “il vaut mieux abstraire après coup en voyant du concret que d’abstraire une pure abstraction” donc dans ce que tu dis ça fit, attends de voir ce qui se passe sur le terrain, XXX des choses qui sont mutualisables. Dans ce cas là on peut trouver une abstraction, dans ce cas là c’est à étudier, en tout cas dans ce sens la ça marche bien il vaut mieux aller du concret vers l’abstrait que l’inverse

Thomas Alors le gagnant du bouquin juste : Nico Chanteaux. est ce que Nico Chanteaux est là ou pas parce qu’il a gagné le bouquin. Ah ben voilà. C’est un super bouquin, il me semble qu’il y a une partie qui parlera à pas à tout le monde mais pour tout le reste XXX au DDD. Bon weekend et place aux castcodeurs