Practical Domain-Driven Design en

Domain-Driven Design doesn’t work for you because it causes too much overhead? It’s too complex to implement and maintain? Too much questions about what should be an aggregate or not ? The concept of bounded-context is somehow fuzzy, what does it have to do with the architecture of my software ?

They say strategic design is the most important but how is this supposed to help me write code?

What if we tried a practical approach of Domain-Driven Design to focus on solving the problem instead of creating new ones?

In this live-coding, we will implement features in a pragmatic and seamless way. By bridging the strategic patterns with the tactical ones, let’s unlock together the full power of Domain-Driven Design.

OAUTH 2.1 explained simply (even if you are not a developer) ! en

It is very difficult today to deploy an application on the web without dealing with OAuth2.

However, haven't you cried trying to understand its concepts? Let's be honest, this is quite easy to get lost between the different roles and flows of this protocol. And its complexity has discouraged more than one!

Don't worry! Whether you have a tech profile or not, this talk will help you to finally understand the intricacies of OAuth simply, including the 2.1 version, using analogies from everyday life!

Model Tension Heuristics: Preventing Accidental Design Debt en

”All models are wrong, but some are useful.” This insight from George Box has become a cornerstone of software modeling. While exploration and experimentation are essential for shaping models, it is often challenging to know when a model is wrong or, worse, when an existing model has become obsolete and is no longer as useful.

As a result, unsuitable models may be still used for a long time, leading to different issues not always identified as forms of design debt. These include the spork effect (intrinsic coupling), model fragmentation (extrinsic coupling), and model sclerosis, which ultimately contribute to entropy or the "Big Ball of Mud" phenomenon. These problems arise from undetected and unresolved model tensions.

In this talk, we will explore what model tensions are, the complications they cause and why they occur. We will also present a set of heuristics to identify and address different kind of model tensions.

Le pattern Hive: une stratégie de modularisation pour votre monolithe modulaire ou vos microservices en

Après une décennie, l'industrie réalise que des microservices mal conçus peuvent facilement se transformer en un monolithe distribué, encore plus problématique que le monolithe en spaghetti qu'ils visaient à résoudre. Pour remédier à ce problème, le concept de monolithe modulaire émerge comme une approche alternative.

Cependant, le défi reste de le scinder efficacement sans tomber dans le piège d'un système fortement couplé et rigide. Comment le modulariser correctement tout en gérant la complexité croissante de votre système ? Comment survivre au-delà de notre dette de modélisation et reprendre le contrôle ?

Découvrez le pattern Hive qui découple votre stratégie de déploiement - monolithe modulaire ou microservices - de la conception de votre logiciel, en adoptant le principe « Model Once, Deploy as you wish ». Ce pattern vous apportera une conception souple et évolutive, résiliente face aux défis changeants pour les produits existants ou en développement.

Hexagonal Architecture in Practice, Live Coding That Will Make Your Applications More Sustainable en

There always comes a point where software becomes so complex and old that it becomes unmaintainable. Updating the technical stack without breaking everything becomes impossible, implementing new features takes longer, and the technical debt is so overwhelming that refactoring becomes exorbitant.

What if we told you that all of this is more of a practice problem than a software aging problem?

Come and discover through hands-on experience in this 100% live coding session how Hexagonal Architecture can tackle software complexity, making it possible for you to be adaptable and sustainable while helping you manage your technical debt more effectively.

The Hive: a modularization strategy for your modular monolith or microservices en

After a decade, the industry is realizing that poorly designed microservices can easily transform into a distributed monolith, even more problematic than the spaghetti monolith they aimed to address. To tackle this issue, the concept of a modular monolith is emerging as an alternative approach.

However, the challenge still lies in effectively splitting it without falling into the pitfall of a tightly coupled and rigid system. How to modularize it right while dealing with the growing complexity of your system? How to survive beyond our modeling debt and take control back?

Discover the Hive architecture style which decouples your deployment strategy - modular monolith or microservices - from the design of your software, embracing the “Build once, Deploy as you wish” principle. The Hive pattern will bring you a supple and scalable design that stands resilient in the face of evolving challenges for brown or greenfield products.

REST next level : Crafting Domain-Driven Designed web APIs en

You have just coded your business logic, and maybe you have even made the effort to apply the principles of Domain-Driven Design!

But when comes the time to write your API, you are facing a serious issue! All the intention and the expression of your domain go up in smoke to fit the blankness methods GET, POST, etc. Denatured by the REST layer, the business logic is then partially reimplemented on the front-end side to compensate for the limited vocabulary of this well-known CRUD protocol...

During this talk, we will see how HATEOAS - the last level of maturity of a REST architecture - can help us write a business-oriented web API that will have the power to guide your consumers through the workflow of your domain.

Osez Devenir Speaker ! en

Devenir Speaker, c’est peut-être quelque chose qui vous fait envie. Mais qu’est ce qui vous empêche d’aller plus loin ?

Sûrement cette petite voix qui vous dit qu’il y a beaucoup de gens plus qualifiés que vous pour parler d’un sujet. Qu’est ce que vous avez à partager de toute manière ? Et puis parler devant une centaine de personnes ce n’est pas pour vous, les gens qui arrivent à faire ça ont certaines prédispositions…

Lors de cette session, nous verrons ensemble que cette petite voix a tort. Vous pouvez le faire ! Et pour bien se lancer, nous verrons les bonnes pratiques de la création d'un talk jusqu'à la réalisation de celui-ci: le choix du sujet, la création du talk et la candidature aux conférences.

Model Mitosis: Stop making the wrong choice between microservices and monolith en

Just as development should be iterative, software design should change when the context and our understanding of the problem evolve. As a software grows to solve more problems, it becomes less supple in its ability to evolve. Tensions arise within the business model of the software that struggles to stay coherent.

Eventually it reaches a critical mass and becomes a monolith of spaghetti code. How do we know when it’s time to modularize our software? How do we carry on the decision to split it into several modules or services? How can we handle the progressive differenciation of our business models while avoiding unnecessary coupling? It’s not as easy as a clean axe cut in the middle, finding the right boundaries can be tricky.

We would like to introduce the Model Mitosis, a dynamic approach used to split a business model into multiple ones that will get shaped and decoupled iteratively. Gain flexibility to choose better when to split into multiple services, and avoid paying the scale cost of microservices or becoming a distributed monolith.

Recording: https://youtu.be/VO6BSb52K5g

Slides: https://slides.com/julientopcu/model-mitosis-a-dynamic-pattern-to-deal-with-model-tensions

Repository: https://gitlab.com/beyondxscratch/model-mitosis

The microservices trend pushed many people to oversplit their software into multiple services, creating distributed monoliths. After a decade of microservices in production, the industry is taking a step back and realizes that splitting too soon will generate important scale costs.

On the other hand, undersplitting the software by stacking evolutions without a modularization strategy will end up creating coupling between all the responsibilities, turning the system into a legacy monolith.

Even though those problems seem different, they are two sides of the same coin: the business model should drive splitting strategies.

It is quite complicated to find a pattern which helps people splitting a model in place while they have to insure the stability and evolution of the application over the duration of the process. People lack heuristics to take decision to spawn a new model and patterns to decide on the boundaries of the system.
In the early stages of the split, the complexity is generally not sufficient to draw the boundaries without overlap.

Julien has first dealt with this problem in production while leading the Train Booking System of Expedia in 2016 and Josian has been working on such issues since 2021 at EDF (French national energy company).

After several years of experimentation, we found a dynamic pattern to split progressively while limiting the coupling between the emerging models. By combining strategy patterns from Domain-Driven Design, we coined the Mitosis Pattern (as an analogy of a cellular mitosis).

It is implemented in 4 steps:
- step 1: a system model grows, the need of a new model emerges

- step 2: the models are split while sharing some concepts into a shared kernel. There are some rules to respect in order to keep it under control.

- step 3 : as models grow apart and specialize, their boundaries get clearer and the shared kernel fades to the minimum (like a strangler fig pattern).

- step 4 : two models isolated from each other, potentially with an anti-corruption layer

This pattern as been presented during DDD Europe 2023 and received great feedbacks such as this one https://twitter.com/tpierrain/status/1666694640660017152?s=20.

This presentation is a livecode, with a storytelling and aesthetics inspired from the TV show the Mandalorians.

With the recent rise of the A.I., we decided to start the reflexion on what could be our relationship to A.I.s in the future as a side take of our talk. With the assistance of several AIs, such as MidJourney 5 and ChatGTP, we created illustrations for our intro and a fake speaking and coding assistant, to illustrate this reflection.

Model Mitosis : ne plus se tromper entre les microservices et le monolithe en

Tout comme le développement doit être itératif, le design du logiciel doit changer lorsque le contexte et notre compréhension du problème évoluent. Au fur et à mesure qu'un logiciel se développe pour résoudre plus de problèmes, il devient moins souple dans sa capacité à évoluer. Des tensions apparaissent au sein du modèle métier du logiciel qui peine à rester cohérent.

Finalement, il atteint une masse critique et devient un monolithe de code en spaghetti... Comment pouvons nous déterminer quand il est temps de modulariser notre logiciel ? Comment prendre la décision de le scinder en plusieurs modules ou services ? Comment gérer la différenciation progressive de nos modèles métiers tout en évitant les couplages inutiles ? Il n'est pas facile de découper son logiciel en deux car déterminer les bonnes frontières peut s'avérer être compliqué.

Découvrez avec nous le Model Mitosis, une approche dynamique utilisée pour diviser un modèle métier en plusieurs modèles qui seront façonnés et découplés de manière itérative. Gagnez en flexibilité afin de mieux déterminer quand diviser votre logiciel en plusieurs services tout en évitant de payer les coût d'échelle des microservices ou bien de devenir un monolithe distribué.

Loi de Conway : Lorsque votre conception produit se fâche avec votre organisation en

Bien que vous suiviez les bonnes pratiques, le logiciel construit s'écarte souvent de la vision produit, technique et parfois même des besoins de l'utilisateur ?

Et si on vous disait qu'il existe une force qui a une influence certaine sur ce que vous produisez ?

Venez découvrir la Loi de Conway qui a un pouvoir sur ce que vous construisez quelque soit votre métier. Nous verrons ses impacts sur les différents aspects du logiciel et nous apprendrons comment l'apprivoiser.

Conway's Law: When Best Practices Are Not Enough en

Your users are still struggling to retrieve the information they need, despite you have done everything to model your domain and ease the user experience?

Although you follow best practices, did you ever noticed that the software often deviates from the product design, the technical vision and sometimes the software quality is even below expectations?

What if we told you that all of this is linked ? There is a force that has an important influence on your product, your user experience, the quality of your software and your architecture !

During this talk, come and discover the Conway's Law that has a magical power over what you build, whatever your job profile is. We will see the impacts of this law on the different aspects of the software based on scientific studies and feedbacks from the field collected over the years.

Comment se faire hacker bien comme il faut! en

Et encore une fuite de numéros de cartes de crédit sur internet! https://www.infoq.com/news/2018/11/british-airways-data-breach

C'est révoltant n'est-ce pas ? Mais attends, qu'est-ce qu'on fait nous pour s'assurer que notre appli n'est pas une passoire?

Dans cette live-coding-hacking session, venez découvrir les erreurs les plus communes en sécurité, que la grande majorité d'entre nous font sans même le savoir!

Après cela, vous ne verrez plus votre application de la même manière...

You thought technical debt was bad? Meet design debt! en fr

In our job, technical debt is probably the most frustrating, draining and tenacious thing we have to fight against. Of course, there are best practices: refactor, aim for simplicity with KISS, avoid over-engineering with YAGNI in order to keep this debt as low as possible. And yet, we never really manage to get rid of it. Worse, it keeps piling up even when we apply those principles, as if it were inevitable.

But what if those very best practices sometimes made the problem worse instead of solving it? Technical debt may be only the visible part of something deeper: accidental design debt. A far more complex problem that leads to spaghetti software and microservices that are really just a distributed monolith, and that we often create ourselves without even realizing it.

In this talk, we will explore the mechanisms of design debt and its impact on our architecture, our processes, our organization, and even our business. Through concrete examples, we will see how to detect it, assess how deep it goes, and act before it becomes entrenched for good.

We want to address the notion of design debt because it is still little known and understood in our industry. Many people are currently bogged down in the fight against technical debt because they are not tackling the real problem, lacking a mental model to reason about design debt (model tensions).

For Devoxx UK, we are proposing a popularized version of our latest talk, “Model Tensions Heuristics: preventing accidental design debt”, presented at NewCrafts 2025 and DDD Europe 2025. The slides and the recording of the original version have been provided.

1. Accidental design debt
Accidental design debt arises from the accumulation of seemingly minor choices that, over time, introduce coupling, reduce cohesion, limit flexibility, and erode the accuracy of business models.
We will highlight the link between this debt and the way we construct our domain models, and show how some best practices (DRY, KISS, YAGNI) can actually make the problem worse, because they are not addressing the right underlying issue.
We will explain how this debt leads to genuine spaghetti monoliths, through design entropy, that is, the tendency of a design to become disorganized and to dissipate ever more of our energy whenever we make changes.
We will introduce the so-called “Spork” model, which consists in trying to solve several distinct problems with one single solution.
2. Model tensions, the origin of design debt
We will introduce the notion of model tension: a “smell” indicating that we are forcing a change into a design that does not really fit it.
We will analyze why these tensions appear and how, as they crystallize over time, they become structural constraints that reinforce design entropy.
We will then put these tensions into perspective not only as a problem, but also as a valuable signal that allows us to anticipate and prevent the emergence of accidental design debt.
3. Practical illustration of these tensions
We will demonstrate these phenomena through several concrete examples:
In the construction of a domain model, in particular via an EventStorming workshop
In the design and structure of a REST API
In Java domain code
For each case, we will present possible remediation paths to identify, correct, or avoid these tensions.
4. The harmful and unsuspected effects of services heavily affected by design debt
We will illustrate the following mechanism: a rigid and complex service leads to the creation of a new microservice to bypass the inertia of an existing service, but functional coupling quickly appears, forcing both services to be deployed together.
We will show how these services eventually form a distributed monolith, because the root problem was never resolved.
We will highlight compensatory responses adopted at the process and organizational levels, such as the use of feature toggles or the emergence of “patch” roles whose purpose is to (over-)synchronize the work of teams in order to avoid making the information system too fragile.
We will analyze the organizational drifts caused by services that are heavily impacted by accidental design debt.
Finally, we will show that these organizational tensions are just another expression of the initial tensions present in the model, including the impact of Conway’s law.
5. Retrospective and ways out
We will show how we built a body of evidence by observing all parts of the company in order to identify and assess the depth of design debt.
We will conclude by opening up concrete levers for action to halt this dynamic and prevent the emergence of new design debt.

Slides Link
https://slides.com/julientopcu/you-thought-technical-debt-was-bad-meet-design-debt

Video URL
https://www.youtube.com/watch?v=EZTl9FH5AFQ

Vous pensiez que la dette technique était le pire? Voici la dette de conception ! en fr

Dans nos métiers, la dette technique est sans doute la chose la plus frustrante, éprouvante et coriace contre laquelle nous devons lutter. Bien sûr, il existe des bonnes pratiques : refactoriser, viser la simplicité avec KISS, éviter de trop anticiper avec YAGNI afin de limiter cette dette au maximum. Et pourtant, on n’y vient jamais vraiment à bout. Pire encore, elle continue de s’accumuler même lorsque nous les appliquons, comme une fatalité.

Et si ces mêmes bonnes pratiques ne faisaient parfois qu’empirer le problème au lieu de le résoudre ? La dette technique peut n’être que la partie visible de quelque chose de plus profond : la dette de design accidentelle. Un problème bien plus complexe, donnant lieu à des logiciels spaghettis et à des microservices en « monolithe distribué », dont nous sommes souvent à l’origine sans même nous en rendre compte.

Dans cette conférence, nous explorerons les mécanismes de la dette de design et ses impacts, conséquents sur notre architecture, nos processus, notre organisation, et même notre business. À travers des exemples concrets, nous verrons comment la détecter, analyser sa profondeur et agir avant qu’elle ne s’ancre durablement.

Nous souhaitons aborder la notion de dette de design car elle est peut connue et comprise dans nos métiers. Beaucoup de personnes se retrouvent aujourd’hui enlisées dans la lutte contre la dette technique, car elles ne traitent pas du véritable problème, faute de grille de lecture sur la dette de design (tensions de modèle). C’est un sujet que nous avions introduit lors de Devoxx France 2024 avec la conférence « Model Mitosis : ne plus se tromper entre les microservices et le monolithe », notée 4,79.

Pour Devoxx France, nous proposons une version vulgarisée de notre dernière conférence “Model Tensions Heuristics: preventing accidental design debt”, présentée à NewCrafts 2025 ainsi qu’à DDD Europe 2025. Les slides et l’enregistrement de la version originale ont été fournis.

Plan de la conférence

1. La dette de design accidentelle

La dette de design accidentelle naît de l’accumulation de choix apparemment anodins mais qui, progressivement, introduisent du couplage, réduisent la cohésion, limitent la flexibilité et altèrent la justesse des modèles métier.
Lien entre cette dette et la façon dont nous construisons nos modèles métier, et mise en lumière de la manière dont certaines bonnes pratiques peuvent aggraver le problème (DRY, KISS, YAGNI), car elles ne traitent pas du bon problème.
Explication de la manière dont cette dette conduit à la création de véritables monolithes spaghettis, sous l’effet de l’entropie du design, c’est-à-dire la tendance d’un design à se désorganiser et à dissiper toujours plus notre énergie lors que l’on procède à des changements
Mise en lumière du modèle dit “Spork”, consistant à vouloir résoudre plusieurs problèmes distincts avec une seule et même solution.
2. Les tensions de modèle, l’origine de la dette de design

Présentation de la notion de tension de modèle : un “smell” qui indique que l’on force un changement à entrer dans un design qui ne lui correspond pas.
Analyse des raisons pour lesquelles ces tensions apparaissent et de la manière dont, en se cristallisant au fil du temps, elles deviennent des contraintes structurantes qui renforcent l’entropie du design.
Mise en perspective de ces tensions non seulement comme un problème, mais aussi comme un signal précieux permettant d’anticiper et de prévenir l’apparition d’une dette de design accidentelle.
3. Illustration pratique de ces tensions

Démonstration de ces phénomènes à travers plusieurs cas concrets :

Dans la construction d’un modèle métier, notamment via un atelier d’EventStorming
Dans la conception et la structure d’une API REST
Dans du code métier Java
Pour chaque cas, présentation de pistes de résolution permettant d’identifier, de corriger ou d’éviter ces tensions.
4. Les effets pervers et insoupçonné des services trop affectés par la dette de design

Illustration du mécanisme suivant : un service rigide et complexe conduit à la création d’un nouveau microservice pour contourner l’inertie d’un service existant, mais un couplage fonctionnel s’installe rapidement, forçant les deux services à être livrés simultanément.
Démonstration de la façon dont ces services finissent par former un monolithe distribué, faute d’avoir résolu le problème à la racine.
Mise en lumière des réponses compensatoires adoptées au niveau des processus et des organisations, comme l’usage de feature toggles ou l’apparition de rôles palliatifs afin de (sur-)synchroniser le travail des équipes pour éviter la fragilité du SI.
Analyse des dérives organisationnelles engendrées par des services fortement affectés par la dette de design accidentelle.
Enfin, mise en évidence du fait que ces tensions au niveau organisationnel ne sont qu’une autre expression des tensions initiales présentes dans le modèle,
Impacte de la loi de Conway.
5. Rétrospective et pistes de sortie

Présentation de la manière dont on a construit un faisceau de preuves en observant l’ensemble des composantes de l’entreprise afin d’identifier et d’évaluer la profondeur de la dette de design.
Ouverture sur des leviers concrets pour agir, enrayer cette dynamique et prévenir sa l’appartion de la dette de design.

Slides Link
https://slides.com/julientopcu/you-thought-technical-debt-was-bad-meet-design-debt
Video URL
https://www.youtube.com/watch?v=EZTl9FH5AFQ

Y’en a marre du software craftsmanship fr

Vous en avez assez qu’on vous dise de faire des kata qui n'ont pas de rapport avec vos problèmes quotidiens ?

Et les coachs ! Ils débarquent avec de grands principes, et imposent des méthodes sans chercher à comprendre vos peines et ce n'est pas le TDD qui va les résoudre. Bref y’en a marre du craft !

Ce talk traite des dérives d’un mouvement qui commencent à écœurer. Nous verrons les défauts de postures, d’implémentations et les croyances qui sont les causes de la défiance envers le craft.

Bien répondre aux besoins utilisateur, c'est surtout une histoire de comportement (logiciel) ! fr

C'est super, tu arrives sur un nouveau projet ! Mais très vite, tu te rends compte que le seul moyen de comprendre ce qu'il fait, est d'aller faire de l'archéologie dans le code. Niveau user stories, elles sont bien définies... pourtant tu ne sais jamais jusqu’où tu dois aller pour les implémenter ! D'ailleurs à chaque fois que tu en livres, tu es a côté du besoin métier...

Et si on te disait que le Behavior-Driven Development pouvait t'aider à résoudre tes problèmes !!

En partant d'une user story, nous allons voir comment en faire émerger les comportements attendus du logiciel. Puis lors de la phase de développement, nous aborderons les pratiques qui permettent d'implémenter et vérifier automatiquement les attentes des utilisateurs.

L'Architecture Hexagonale par la pratique, le live coding qui rendra vos applications plus pérennes fr

Il arrive toujours un moment où, le logiciel est tellement gros et vieux qu’il devient inmaintenable. Impossible de mettre à jour la stack technique sans tout casser, les nouvelles fonctionnalités deviennent de plus en plus longue à implémenter et la dette technique étant tellement lourde que le refactoring devient exorbitant.

Et si on vous disait que tout ça était plus un problème de pratique qu’un problème de vieillesse du logiciel ?

Venez découvrir par la pratique via ce 100% live coding, comment l’Architecture Hexagonale peut tacler la complexité logicielle en vous permettant d’être évolutif et pérenne tout en vous aidant à mieux gérer votre dette technique.

OAuth 2.1 expliqué simplement (même si tu n'es pas dev) ! fr

Il est très difficile aujourd'hui de déployer une application sur le web sans se frotter à OAuth2. Conçu pour mieux protéger les utilisateurs et utilisatrices, ce standard de délégation d'autorisation s'est totalement imposé dans l'industrie.

Cependant, n'avez-vous pas pleuré en essayant de comprendre les concepts de OAuth2 ? On ne va pas se mentir, entre les différents rôles et la multitude de flows qui le constituent, il y a vraiment de quoi se perdre et sa complexité en décourage plus d'un ! Et pourtant, on ne peut pas s'en passer, donc on y va et généralement c'est douloureux…

Mais ne vous inquiétez pas, que vous ayez un profil tech ou non, ce talk va vous permettre d'enfin comprendre les méandres de OAuth simplement, dont la nouvelle version 2.1, en s'appuyant sur des analogies de la vie courante !