Votre code au défi de l’onboarding ? fr

L'équipe en charge d'une application reste rarement la même de son inception à son décommissionnement.

En tant que développeurs, vous l’avez sûrement déjà vécu : arriver sur un nouveau sujet, c’est rarement simple. Pour être capable de faire les bons choix, de nombreuses connaissances doivent être assimilées. Alors combien de temps pour être pleinement efficace ? N’est-il pas possible de rendre le code plus “accueillant” ?

Dans cette présentation, nous vous montrerons, en nous basant sur une application d’exemple, les techniques que nous avons pu mettre en place sur différents projets pour documenter, expliciter, automatiser, simplifier, tester... Bref, pour fluidifier la transmission de connaissances et faire en sorte que les nouveaux arrivants ne nous détestent pas trop.

L'idée est d'utiliser un projet d'exemple en fil rouge pour montrer les concepts : ADRs, spec/contrat d'API, Gherkin, diagrams as code, annotations documentaires, ArchUnit, etc. Puis de nous servir de nos expériences et de concepts théoriques pour prendre un peu de recul par rapport à tout ça.

Hands on Property-Based Testing in Java en

As a developer, unit tests are something you have mastered. Testing some behaviour by identifying a few relevant examples has become almost automatic to you… However, is this approach as natural as it seems? Wouldn’t you agree that your tests could describe the business domain more efficiently, without bothering with examples and the bias they introduce?

This is the main idea behind Property-Based Testing: unlike the traditional “Example-Based” testing, you get to define the “properties” that you want your code to exhibit, and then it’s up to the engine to try and find examples that will expose your mistakes!

The purpose of this workshop is to get a feel for Property-Based Testing with Java / JUnit 5 framework Jqwik. You will end up with a clear picture as to why it would make your job easier, when to use it and when not to, along with everything necessary in order to start using it in your projects!

Enforcing architecture decisions with ArchUnit en

Qu'elles soient prises par des comités d'architectes ou par les équipes directement en contact avec le code, le suivi des décisions d'architecture est souvent problématique. Pour des contextes Java, ArchUnit propose une solution par la formalisation de ces décisions sous la forme de tests intégrés à l'application.

Cette présentation vous donnera les éléments pour décider de la pertinence d'ArchUnit dans votre contexte et pour le mettre en place en toute simplicité.

Sortir des ORMs avec jOOQ fr

Hibernate, Entity Framework, JPA… Ça fait maintenant des décennies que les ORMs sont parmi nous. En tant que dev, bien souvent, on sait s’en servir, mais ce qu’il y a derrière, c’est un peu un mystère. C’est pratique, ça fait gagner du temps, mais cette magie a un coût qu’on paie bien souvent plus tard : requêtes complexes, mauvaises performances, comportements différents selon les contextes…

Et pourtant, depuis plusieurs années, des alternatives comme jOOQ sont en train de prendre une place de plus en plus importante. Leur credo : on jette l'ORM à la poubelle et on revient à du bon vieux SQL, mais type safe.

Lors de cet atelier, disponible en Java et en Kotlin, vous travaillerez sur une application Spring / JPA, comme on en rencontre beaucoup, pour y intégrer jOOQ. Nous verrons comment sortir, étape par étape, de cette dépendance néfaste aux ORMs. Ce sera l'occasion de découvrir combien cela permet d'évoluer vers un code plus simple, plus standard, plus expressif. Et que ce n'est même pas compliqué.

Il s’agit d’un atelier à destination des devs de l'écosystème Java, disponible dans 2 contextes : Kotlin/Gradle et Java/Maven.
Il a déjà été donné à Devoxx France 2025 ainsi qu’à l’occasion d’une journée de partage Shodo.
Le dépôt de code utilisé comme support est disponible sur Github : https://github.com/sylvaindecout/jooq-handson.

Service Mesh - Reprenons les bases fr

Le concept de Service Mesh est à la mode depuis quelques années. Et pour cause, il apporte de grands bénéfices dans une architecture en microservices... Mais ça veut dire quoi, tout ça, au juste ?

Cette présentation repart des bases pour vous donner une vision claire de ce qu'est un Service Mesh et de ce que ça peut vous apporter concrètement.

Plan de la présentation :
* L'orchestration c'est quoi ?
* Les concepts de base de Kubernetes
* Un Service Mesh c'est quoi ?
* Les concepts de base de Istio
* L'écosystème des Service Mesh en 2022

Un code à l'épreuve du temps avec le Supple Design fr en

Avec le temps, beaucoup d’applications ont tendance à devenir de plus en plus lourdes, jusqu’à atteindre un point où tout changement devient si coûteux qu'il vous sera impossible de vous adapter aux besoins de vos utilisateurs. C'est le signe d'une conception rigide. L'adoption de Clean Code et des patterns tactiques de DDD peut rendre la situation supportable, mais on reste en surface ; le problème sous-jacent reste présent.

Ça tombe bien, le Domain-Driven Design propose toute une section, trop souvent oubliée, sur le « Supple Design ». Elle fournit des techniques pour tendre vers une conception flexible, qui pourra s'adapter simplement aux évolutions futures. En somme, un code sur lequel il est, et sur lequel il restera, un plaisir de travailler.

Ces principes qui datent de plus de 20 ans sont-ils toujours d'actualité ? Comment s'articulent-ils avec d'autres concepts qui ont émergé depuis ? En quoi constituent-ils un ensemble cohérent ? Afin de répondre à ces questions, je vous propose un live coding au cours duquel nous passerons en revue chacun des principes du Supple Design en nous appuyant sur des exemples concrets.

Cette présentation comporte des parties de live coding qui se basent sur ce repository : https://github.com/sylvaindecout/supple-design-sandbox.

Elle a déjà été donnée en Mars 2023 lors d'une journée de partage Shodo consacrée au DDD, ainsi qu'à l'édition 2024 de Breizhcamp (captation disponible ici : https://www.youtube.com/watch?v=ZEcJEhgoi1E).

Supple Design - Aiming for code meant to age well fr en

As time goes by, most applications tend to grow heavier and heavier. At some point, any change becomes so expensive that you may not be able to adapt to the needs of your users anymore. This is the sign of a rigid design. Techniques from tactical DDD or clean code do help make your code easier to maintain; however, they only address the surface, not the underlying model.

Thankfully, DDD happens to include a whole section, often overlooked, called "Supple Design". It provides techniques to reach for a design that can easily adapt to future needs. To put it simply: code that is -and will remain- a pleasure to work with.

Are these techniques from 20 years ago still relevant? How do they articulate with other concepts that have appeared since then? In order to answer these questions, let us review each of the principles of Supple Design, illustrate them with some live coding, and see how they make sense as a whole.

This talk includes live coding, based on this code repository: https://github.com/sylvaindecout/supple-design-sandbox.

A first version of this talk was given in 2023 on the occasion of a knowledge sharing day dedicated to DDD at Shodo Paris. It was then presented at Breizhcamp in 2024 (recording available here: https://www.youtube.com/watch?v=ZEcJEhgoi1E).