Immersion chez les Software Crafters : une journée pour pratiquer le craft
Arthur, Lead Développeur Java chez Peaks, a récemment participé à une journée d’ateliers craft organisée par la communauté Software Crafters Lyon dans les locaux d’Ada Tech School.
L’objectif : expérimenter, en conditions réelles, plusieurs pratiques plébiscitées du Software Craftsmanship, parmi lesquelles :
- Le Test-Driven Development
- Le Pair/Mob programming
- L’Architecture Hexagonale (front et back)
- Le Refactoring
- Le Functional Programming
- Le Domain Driven Design
- L’Event Sourcing
Contrairement à une conférence plus classique, où l’on reste souvent passif, même si en écoute active, cette journée proposait un format actif et immersif. Chaque participant était invité à réaliser un exercice de codage guidé pour découvrir un thème ou un sujet spécifique.
Voici les différents thèmes craft de la journée :
Parmi ces ateliers craft, Arthur a particulièrement apprécié l’Event Sourcing step by step, présenté par Romain Berthon. Il vous partage ici ses apprentissages et son retour d’expérience.
Mais d’abord, définissons rapidement l’Event Sourcing.
Qu’est ce que l’Event Sourcing ?
C’est un pattern architectural qui consiste à stocker l’ensemble des événements (immuables) d’un système et non pas uniquement l’état actuel des données, traditionnellement mis en oeuvre.
Il a notamment pour avantage d’amener une traçabilité et un historique complet des actions ayant eu lieu sur les entités du système.
Passons maintenant à la pratique !
Retour sur l’atelier craft « Event Sourcing step-by-step »
L’atelier présente un système représentant une ampoule, modélisé ainsi :
- L’ampoule peut recevoir les commandes Allumer ou Éteindre qui ont un effet uniquement si l’ampoule est respectivement Éteinte ou Allumée.
- L’ampoule peut être allumée un certain nombre de fois, après quoi elle est cassée et ne fonctionne plus.
L’exercice commence donc par implémenter ces différentes règles métiers de manière classique.
Modéliser l’état du système
On s’aperçoit alors que pour déterminer l’effet de la commande reçue par le système (Allumer/Éteindre), nous avons besoin de sauvegarder l’état du système, à savoir :
- L’ampoule est-elle cassée ou fonctionnelle ?
- Si elle fonctionne :
- Est-elle allumée ou éteinte ?
- Combien d’allumages restants possède-t-elle encore ?
La première étape est donc la suivante :
Séparer les responsabilités : decide / evolve
Dans une seconde étape, nous découpons les responsabilités entre notre fonction decide qui détermine un événement et une fonction evolve qui applique les effets de cet événement couplé à l’état précédent pour en déduire le nouvel état.
Les événements peuvent être :
- L’ampoule s’est allumée
- L’ampoule s’est éteinte
- L’ampoule s’est cassée
Faire évoluer l’état à partir d’une liste d’événements
Nous faisons ensuite évoluer notre fonction evolve pour qu’elle puisse traiter une collection d’événements (même si la collection n’a qu’un seul élément dans un premier temps), grâce à la récursivité ou Stream.reduce (pour Java)
C’est aussi à ce moment-là que nous commençons également à persister ces événements en mode append only
Nous nous rendons alors compte que globalement, nous avons quelque chose comme cela :
Notre fonction evolve pouvant traiter une collection d’événements, nous pouvons alors simplifier cela ainsi :
On remarque alors que la persistance de l’état à chaque commande reçue n’est plus nécessaire.
Lorsque l’on reçoit une commande :
- On calcule à la volée l’état du système avant la commande en appliquant tous les événements passés à partir de notre état initial
- Puis la commande et notre état temporaire détermine les nouveaux événements à appliquer pour obtenir notre nouvel état
Nous obtenons donc un système pour lequel nous ne persistons plus que les événements du système et plus son état.
L’application des effets de cet ensemble d’événements nous permet à chaque instant de reconstruire l’état de notre système.
Nous avons donc réussi à implémenter ce qu’on appelle une architecture Event Sourcing où nos événements sont notre source de vérité primaire.
NB : aller jusqu’au 100% événementiel
Pour obtenir un système 100% événementiel et ne plus garder la mémoire de notre état initial, nous pouvons alors :
- Considérer cet état initial comme une constante, toutes les ampoules seront les même
- Considérer une commande d’initialisation de l’ampoule qui déterminera un événement d’initialisation également avec les caractéristiques propre à une ampoule
Consignes et correction (en F#) de l’atelier disponibles ici :
https://github.com/RomainTrm/Workshop-Event-Sourcing-Crafters
Le bilan d’Arthur sur cette journée craft et l’atelier Event Sourcing, step by step
J’ai beaucoup apprécié cette journée d’ateliers et ai trouvé intéressant les concepts explorés.
De plus, la plupart des ateliers peuvent être réalisés dans le langage de son choix, nous ne sommes pas figés sur une techno, puisque que ce sont plus des concepts et des designs dont il est question.
Enfin, comme ce sont des ateliers qui se prêtent très bien au pairing, c’est aussi l’occasion de rencontrer d’autres personnes de la communauté dev lyonnaise et retrouver d’anciens collègues parfois aussi 😉
Pour information, les Software Crafters sont un des groupes tech les plus actifs à Lyon à ma connaissance. Je vous encourage vivement à aller tester par vous-même, notamment les coding dojos (en présentiel ou en ligne), auxquels je participe régulièrement. Ils sont organisés plusieurs fois par mois :
https://www.meetup.com/fr-fr/software-craftsmanship-lyon
