Du 05 au 07 Février 2020 nous (Anthony et Colin avons eu la chance de passer 3 jours à DDD Europe. Autant spoiler tout de suite : c'était vraiment 3 très belles journées, on vous raconte !
Matinée Event Sourcing :
Il y a plusieurs formules pour participer à DDD Europe. Nous avions pris un combo avec une première journée dédiée à l'Event Sourcing. Nous commençons donc avec trois talks sur le sujet :
- [Event Sourcing] Keynote par Udi Dahan ;
- Mistakes Made Adopting Event Sourcing (and how we recovered) par Nat Pryce ;
- Event Sourcing Done Right - Experiences from the Trenches par Dennis Doomen.
Dans notre perception, ces trois premiers talks étaient relativement similaires : d'abord une introduction à l'Event Sourcing puis une mise en garde de n'utiliser cette approche que si on en a réellement besoin.
Les 3 speakers ont bien insisté sur le fait que l'Event Sourcing augmente drastiquement les risques d'erreurs dans le développement. On ne parle pas ici du risque de faire des traitements faux mais bien des risques d'erreurs très coûteuses dans l'architecture logicielle. Ils ont aussi largement insisté sur la complexité accidentelle qu'ajoute cette approche.
Quelques temps avant cette conférence, Anthony avait eu la chance de participer à 3 jours d'ateliers avec Adam Dymitruk et Greg Young sur CQRS et l'Event Sourcing. À cette occasion nous avions pu échanger avec ces deux porteurs de la discipline. Pour leur part ils font systématiquement de l'Event Sourcing (quelle que soit la mission).
Avant d'échanger avec eux sur ce sujet nous étions persuadés que l'Event Sourcing n'était adapté que dans certains cas bien précis :
- très importants volumes de données et de traitements,
- CQRS avec beaucoup de projections et d'importants risques en cas de perte de la cohérence à terme,
- fort besoin de traçabilité,
- présence d'une équipe expérimentée pouvant comprendre ce type d'architectures.
De fait, nous étions étonnés du discours tenu et, pouvoir entendre des avis similaires au nôtre dans les talks de DDD Europe nous a conforté dans nos convictions. En fait, il est tout à fait normal pour ces deux fers de lance de l'approche de ne faire que ça. Pour les autres développeurs, par contre, il semble qu'il soit important de ne pas considérer tous les problèmes comme des clous, mêmes lorsqu'on a un superbe marteau !
De ces trois premiers talks, si nous ne devions en retenir qu'un, ce serait celui de Dennis Doomen qui semblait plus expérimenté sur cette approche et donnait des retours vraiment intéressants.
Functional Event Sourcing par Jérémie Chassaing
On commence l'après-midi avec un talk présenté sous forme de live coding, Jérémie Chassaing nous montre comment cloisonner un domaine métier (le fonctionnement d’une ampoule) de son infrastructure basée sur de l’Event Sourcing.
Aucun slide, un IDE, une en-tête en F# pour mettre quelques informations personnelles et Jérémie lance son live coding.
Jérémie, commence par représenter le Domain d’une ampoule avec les états "Allumé", "Éteint" et les actions "Allumer" et "Éteindre" à travers le système de typage du langage.
On voit tout de suite la pertinence du typage fort qui permet de rendre explicite chacun des états et chacune des actions.
Pour ajouter un peu de complexité au domaine métier de l’ampoule et justifier l’intérêt de l’Event Sourcing, il ajoute une règle métier qui casse l’ampoule au quatrième allumage, ce qui introduit l’état "Cassé".
Ainsi il devient facile de déduire les évènements associés "Ampoule allumée", "Ampoule éteinte" et "Ampoule cassée".
Il insiste sur le fait que sa représentation du domaine est immuable, c’est-à-dire que les valeurs correspondant à ses types ne peuvent pas changer (un peu comme si tous les fields de vos objets n’étaient accessibles qu’en lecture) et ses fonctions donneront toujours le même résultat si les mêmes paramètres sont passés en entrée (on appelle ça des fonctions pures).
Ensuite, Jérémie décide d’implémenter un event store en mémoire. Ayant séparé le métier de son infrastructure (le domaine de l’ampoule, du système de persistance des évènements en mémoire), il peut s’attaquer à une seconde implémentation en persistant dans un fichier. Suite à cette implémentation, Jérémie ajoute un dernier adaptateur pour la solution Event Store.
À travers tous ces exemples d’implémentation, Jérémie aura montré un domaine métier cloisonné de l’infrastructure. À aucun moment il n’aura eu besoin de retoucher ses règles métiers, seulement les adaptateurs vers son infrastructure et ainsi démontrer l’intérêt d’une architecture hexagonale.
Ce live coding est une très bonne introduction à l'architecture hexagonale et ses bénéfices puisqu’il permet, à travers une application concrète, de montrer les avantages de séparer les adaptateurs du Domain afin de ne pas retoucher le code métier. De plus l’immutabilité au sein du code métier est bien amenée et le typage fort utilisé rend le sujet explicite. Un très bon live coding qui regroupe plusieurs notions du DDD tout en restant très simple et sans volonté d’impressionner son public comme le rappelle Jérémie.
Dissecting Bounded Contexts par Nick Tune
On commence cette première journée de Main Conference par une keynote très bien menée par Nick Tune. Il commence par rappeler l'importance du langage avec des exemples bien choisis et plein d'humour :
- "JavaScript is not related to Java",
- "There is no Straw in Strawberries",
- ou encore une image comme celle-là :
C'est vrai que l'on peut légitimement se demander quels sont les points communs entre une "Fairy" et un "Ferry" alors qu'on entend clairement la même chose !
Il nous parle ensuite de l'importance des Bounded Contexts avec, là encore, un exemple plein d'humour concernant les tomates. En fait, dans le contexte de la science les tomates sont des fruits par contre, à cause d'une loi américaine, dans le contexte de la cuisine, les tomates sont des légumes.
Il revient ensuite sur les notions de Core Domain, Generic Domain et Supporting Subdomain pour proposer un différenciation qu'il détaille dans un article medium. Cette nouvelle vision apporte vraiment un plus et nous la verrons probablement intégrer les prochains ouvrages sur le DDD !
Il revient ensuite sur l'organisation des équipes (qui est intrinsèquement liée aux découpage des Bounded Contexts). Pour lui, nous n'avons pas encore trouvé d'organisation d'équipe répondant vraiment à toutes les contraintes de notre marché.
Pour expliquer cela il commence par présenter les interactions entre l'équipe et les clients de cette manière :
Avec ce cycle en tête, il est essentiel que les différentes équipes travaillant à la réalisation d'une solution (et donc travaillant sur des Bounded Contexts ayant beaucoup d'interactions) puissent partager efficacement leurs compétences et décisions.
Dans une organisation avec des équipes figées il y aura forcément de la perte d'information (même avec des canaux de communication privilégiés). À l'inverse, on ne peut pas faire changer les équipes de contexts trop régulièrement au risque de perdre en vélocité.
Nick propose alors une organisation dans laquelle une personne change régulièrement d'équipe mais ou on garde ce qu'il appel un team lead (que nous avons compris comme étant un tech-lead). On obtient alors une organisation comme celle-ci :
Cette seconde journée pour nous (mais la première pour beaucoup) commence donc très très fort avec un talk inspirant et fort bien mené, vivement la suite !
Blink Modelling par Alberto Brandolini
On enchaîne par un atelier d’EventStorming animé par Alberto Brandolini : créateur de la méthode. Le but de l'atelier est de représenter le domaine métier d’une banque décrit par Brian, un visiteur de l’évènement.
Nous avons eu tellement de retours à faire sur cet atelier que nous les avons détaillés dans un article dédié.
Combatting the Near Enemies of Domain Driven Design - at Scale! par Andrew Harmel-Law et Gayathri Thiyagarajan
Cette journée valait déjà à elle seule le déplacement et le billet, nous étions comblés et n'attendions même plus rien de spécial à ce moment-là. Puis, arrive ce talk, Gayathri, Andrew et les "Near Enemies" : une notion du bouddhisme.
Un "Near Enemy" est souvent bien plus dangereux qu'un "Far Enemy" du fait qu'il est bien plus difficile à détecter ! Pour prendre un exemple éloigné de l'informatique : le déni est un "Far Enemy" de l'acceptation, par contre, la passivité et la résignation sont eux des "Near Enemies" (de l'acceptation).
L'idée ici était de présenter les "Near Enemies" du DDD qu'ils ont dû combattre dans un contexte où ils sont tous les deux intervenus mais aussi les solutions pour combattre chacun d'entre eux.
Voici quelques-uns des conseils que nous avons retenus de cette conférence :
- Il faut s'assurer que tous les livrables de Design sont faits en prenant en compte les personnes auxquelles ils sont destinés ;
- Il ne faut pas faire des abstractions trop tôt, en tout cas, pas avant d'être certain d'avoir bien compris les subtilités du Domain ;
- Il ne faut pas partager le code entre plusieurs équipes à moins que cela ne soit absolument nécessaire. Pour être honnête nous avons déjà expérimenté bien trop souvent les problèmes posés par des Shared Kernels trop imposants, donc nous connaissons bien celui-là, mais on voulait quand même le remettre ici :) ;
- Hands on modelers est VRAIMENT un point important du DDD. Si la personne qui fait des schémas sur les tableaux ne participe pas à la réalisation du code alors ses modèles seront probablement inutiles. Toute personne participant au projet qui peut coder DOIT coder, pour les personnes qui ne peuvent pas coder elle doivent pairer avec des personnes qui peuvent coder ;
- Le modèle du Domain doit être fait par l'équipe, pas par une personne externe ;
- Pensez aux relations entre les membres des équipes lorsque vous découpez vos Bounded Contexts.
Si vous voulez voir le talk (en attendant la publication des vidéos de DDD Europe) ils l'ont donné au Virtual Domain-Driven Design et il est donc disponible sur YouTube.
A Story of Mob Programming, Testing and Everything par Elisabeth Hocke
En parallèle des lightning talks, pour terminer ce deuxième jour, Elisabeth (Lisi) Hocke, une testeuse, revient sur son expérience du MOB programming.
Elle replace son contexte en abordant le Pair Programming très présent dans son équipe et s’en sert de levier pour aborder la notion de Mob Programming mise en place au sein de son équipe.
"All the brilliant people working on the same thing, at the same time, in the same space, and on the same computer."
Elle rappelle les rôles : le driver (celui qui code), le navigator (celui qui instruit) qui sont déjà présents dans le Pair Programming, auquel s’ajoute le rôle du Mob (l’assistance).
Notre but ici n'est pas de détailler le fonctionnement du Mob Programming. En fait ce talk nous a donné envie de faire un article dédié.
Elle soulève ainsi l’importance de l’apprentissage de tous les participants en insistant sur l’importance de la bienveillance, la considération et le respect :
Treat each other with kindness, consideration and respect
Elle décrit son tout premier mob avec une matinée bien remplie :
- 9h45 Setup
- 10h Introduction
- 10h10 Mobbing
- 11h15 Retrospective
- 12h10 Closing
- 12h15 Lunch :)
En se basant sur ses expériences tirées du monde réel, elle nous expose quelques points d’attention sur le mob :
- La disponibilité de la salle ;
- Les setups différents sur les machines ;
- Le périmètre d’une story ;
- Les personnes à distance ;
- Le côté trop formel de l’atelier.
Et pour répondre à ces points, son équipe a mis en place les solutions suivantes :
- Utiliser son bureau ;
- Être plus flexible ;
- Adapter les rotations en fonction des compétences et connaissances de chacun ;
- Tout le monde contribue ;
- Le Mob en tant que navigator ;
- Autoriser des Mobs partiels (avec certains participants absents).
Avec toutes ces évolutions, elle revient sur les apports du Mob en terme d’évolution personnelle ; sur ce qu’enseigne la méthode ; sur la force des contributions de chacuns.
Elle insiste sur les apports du Mob en termes :
- d’écoute,
- de communication,
- de collaboration synchronisée,
- d’empathie,
- d’observation,
- de capacité à laisser tout le monde s'exprimer,
- d’aide à faire grandir les autres,
- des autres façons de faire que la sienne.
Ensuite, elle aborde une phase de doute vis-à-vis de la méthode puisqu’en Mob, il n’y a tout de même qu’une seule personne qui code à la fois, comment peut-on rester productif alors que sans, tout le monde code en parallèle. À ce moment, elle cite une phrase de Woody Zuill qui prend tout son sens :
"I’d rather work slowly on the right thing than quickly on the wrong thing"
Ainsi elle rappelle que tous les avantages du Pair Programming, tels que le partage des compétences et des connaissances … sont multipliés et améliorés avec le Mob. Elle parlera de bonne méthode pour des onboarding, d’absence de changement de contextes, de l’instantanéité du partage d’information …
Elle nous parle ensuite des impacts de la non pratique du Mob qui a pour conséquences de :
- moins partager,
- moins apprendre,
- perdre de l’information,
- plus retravailler l’existant,
- selon elle, d’être moins fun.
Elle indique qu’il ne faut pas faire du Mob lorsque le problème à traiter est confidentiel, administratif ou trop simpliste mais qu’il est intéressant d’en faire pour tout le reste.
Elle insiste sur l’idée de faire des pauses lorsque les sessions sont trop intenses.
Pour terminer, elle indique que pour faire du Mob, il est important de rendre l’atelier facile et d’y aller progressivement en commençant par le préparer avec un but clair. Ensuite il est important de le mettre en place rapidement, de désigner un Navigator et un facilitateur. Puis de commencer par une petite contribution timeboxée à une ou deux heures au début afin de terminer l’atelier dans un bon état d’esprit.
Avec son support très simple à suivre et son aisance à l’oral, Lisi a su nous faire passer de nombreuses informations sur son retour d’expérience. C’est sans doute un des talks les plus marquants que nous avons pu voir dans toute la sélection du DDD Europe. On sentait qu’elle avait envie de partager tout ce qu’elle a vécu durant ses ateliers de Mob Programming ainsi que les enseignements qu’elle en a tiré professionnellement, mais également, personnellement.
Fin de journée
Ainsi se termine cette première journée de la Main Conference. Si la première journée dédiée à l'Event Sourcing était intéressante, pour nous, la première journée de la conférence principale a été bien au dessus.
Nous avons choisi de ne parler que des talks qui nous ont marqués mais on ne pouvait pas terminer sans dire qu'on a eu la chance de se retrouver à la table d'Alberto Brandolini pour le dîner. Nous avons ainsi pu poser différentes questions que nous avions suite à l'atelier fait dans la matinée !
Nous avons terminé cette journée éprouvante très tôt car le Main Event était pour le lendemain avec une journée commençant sur les chapeaux de roues mais ça, ce sera pour un autre article :)
