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

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.

Y’en a marre du software craftsmanship

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.

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

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

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 !

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.

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

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 !

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

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

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

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.

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

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.

Conway's Law: When Best Practices Are Not Enough

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!

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

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

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.