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 microservice 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...

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 !