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.

The Hive: a scaling and supple architecture style for your growing and complex domain

In a landscape of scaling domain complexity and evolving responsibilities, organizations often grapple with the question of whether to adopt microservices. The ubiquity of Big Ball of Mud (BBOM) monoliths has reshaped the conversation, challenging conventional notions of system design. However, the deployment strategy for bounded contexts remains elusive. How to split it right by avoiding the pitfalls of a distributed big ball of mud ? How to ensure the cohesion and consistency of our bounded-contexts ? How to reduce coupling between them ? How to deal with the growing complexity of your system ? How to survive beyond our modeling debt and take control back ? Discover the Hive architecture style, a tactical approach that enables you to cope your strategic challenges and align your software business core with your context map. This pattern decouples your deployment strategy from your strategic design, adhering to the principle of “Model once, Deploy as you wish”. By rationalizing the relationship between bounded-contexts and services, 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.

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

[2h]Architecturoplastie hexagonale d’un backend Node.js : Opération à code ouvert

Votre backend n'a même pas 3 ans et pourtant, il n’est pas en forme. Il devient difficile d’y ajouter de nouvelles fonctionnalités, de maintenir et/ou de refactorer l’existant. Le code est intolérant à la montée de versions de librairies, pouvant lui causer une régressionnite fonctionnelle aiguë. Les tests deviennent douloureux à l’écriture. Les précédents choix techniques ont comme effet secondaire de limiter ou verrouiller l’évolution du logiciel, à un point où il devient tentant de repartir de zéro. Votre backend commence lentement à pourrir, son architecture s’étant sclérosée. Mais savez-vous qu’il existe différents types de complexité logicielle ? Et que bien les identifier en les séparant avec un pattern d’architecture adapté, peut améliorer la pérennité de nos applications ? Et tout ça, quels que soient les frameworks que vous utilisez ? Dans cette opération à code ouvert sous forme d’un mob-programming intéractif, venez découvrir comment redonner un coup de jeune à votre backend à bout de souffle en le faisant migrer vers de l’Architecture Hexagonale.

Model Mitosis: a dynamic pattern to deal with model tensions

Just as models should be iterative, strategic design should change when the context and our understanding of the problem evolve. As a model grows to solve more problems, it becomes less supple in its ability to evolve. Tensions arise within the model that struggles to stay coherent. Eventually it reaches a critical mass and becomes a big ball of mud. How do we know when it’s time to let new models emerge? How do we carry on the decision to split a model? How can we handle the progressive differentiation of our models while avoiding unnecessary coupling? It’s not as easy as a clean axe cut in the middle, finding the right boundaries is hard. We would like to introduce the Model Mitosis, a dynamic pattern used to split a model into multiple ones that will get shaped and decoupled iteratively.

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.

Y'en a marre du Software Craftsmanship!

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

It is very difficult today to deploy an application on the web without dealing with OAuth2. Designed to better protect users, this authorization delegation protocol has become a standard in the industry. However, haven't you cried trying to understand the concepts of OAuth2? Let's be honest, this is quite easy to get lost between the different roles and the multitude of flows of this protocol. And its complexity has discouraged more than one! However we can't deliver without it, so we try to setup some OAuth flow and usually... this is really painful. But 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 new version 2.1, using analogies from everyday life!

Train Booking Context Map

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

Des utilisateurs qui ont toujours du mal à récupérer les informations dont ils ont besoin, alors que vous avez mis le paquet sur l'expérience utilisateur ? La frustration de voir qu'une fonctionnalité implémentée est rarement la solution fonctionnelle idéale que vous aviez défini, car il y a toujours un "mais" ? Ou plus techniquement, avez-vous des APIs découpées d'une manière qui semble au final arbitraire et qui ne suit pas le métier ? La sensation que votre organisation est orthogonale à vos objectifs ? N'avez-vous jamais remarqué, que bien que vous soyez agile et vous suivez les bonnes pratiques, le logiciel qu'on construit s'écarte souvent de la vision produit, technique et parfois même des besoins de l'utilisateur que l'on a pourtant passé du temps à récolter ? Et si on vous disait que tout cela est lié, et qu'il existe une force qui a une influence certaine sur votre produit, votre expérience utilisateur et votre architecture ? Lors de ce talk venez découvrir la Loi de Conway, cette force méconnue qui a un pouvoir magique sur ce que vous construisez quel que soit votre métier. Nous verrons ses impacts sur les différents aspects du logiciel et nous apprendrons comment l'apprivoiser.

[LBC] 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.

REST next level : Crafting Domain-Driven Designed web APIs

You have just coded your business logic by applying 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 workflow is then deported on the consumer side to compensate for the limited vocabulary of this well-known CRUD protocol... During this talk, we will see how to bring the business intent back inside the REST API by finally being able to expose our domain services and agregates' methods. The business workflow will also be encapsulated in the REST API in order to have the power to guide our consumers through the workflow of our domain.

Architecturoplastie hexagonale d’un backend Node.js : Opération à code ouvert

Votre backend n'a même pas 3 ans et pourtant, il n’est pas en forme. Il devient difficile d’y ajouter de nouvelles fonctionnalités, de maintenir et/ou de refactorer l’existant. Le code est intolérant à la montée de versions de librairies, pouvant lui causer une régressionnite fonctionnelle aiguë. Les tests deviennent douloureux à l’écriture. Les précédents choix techniques ont comme effet secondaire de limiter ou verrouiller l’évolution du logiciel, à un point où il devient tentant de repartir de zéro. Votre backend commence lentement à pourrir, son architecture s’étant sclérosée. Mais savez-vous qu’il existe différents types de complexité logicielle ? Et que bien les identifier en les séparant avec un pattern d’architecture adapté, peut améliorer la pérennité de nos applications ? Et tout ça, quels que soient les frameworks que vous utilisez ? Dans cette opération à code ouvert sous forme d’un mob-programming intéractif, venez découvrir comment redonner un coup de jeune à votre backend à bout de souffle en le faisant migrer vers de l’Architecture Hexagonale.

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

OAuth2.1 expliqué simplement (même si tu n'es pas dev) !

Architecture Hexagonale : un pattern de gestion de la complexité logicielle et de la dette technique

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 ce retour d’expérience, 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.

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

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

REST next level : Ecrire des APIs web orientées métier

Vous venez de coder votre logique métier, et peut-être que vous avez même fait l'effort d'appliquer les principes du Domain-Driven Design ! Mais au moment de l'écriture de votre API... Catastrophe ! Toute l'intention et l'expression de votre domaine partent en fumée pour rentrer dans le moule des méthodes GET, POST, etc. Dénaturé par la couche REST, le métier se voit alors en partie réimplémenté côté front pour compenser le vocabulaire limité de ce protocole basé sur un CRUD... Lors de ce talk, nous verrons comment HATEOAS - le dernier niveau de maturité d'une architecture REST - peut nous aider à écrire une API web orientée métier qui aura la puissance de guider vos consommateurs à travers le workflow de votre domaine.

[BDX.io 2019] Architecture Hexagonale Level 2 : Comment bien écrire ses tests

De plus en plus d’équipes adoptent l’architecture hexagonale comme structure de prédilection pour leurs applications métiers, mais peu d’entre elles savent réellement bien les tester. Et malheureusement lorsque l’on se plante sur ce point, la maintenance de notre architecture hexa devient un véritable calvaire! Lors de ce talk, nous allons aborder les 5 niveaux de tests préconisés pour les microservices adaptés à l'architecture héxagonale. Et en prime comment avoir une documentation drivée par les tests. Venez découvrir à côté de quoi vous êtes peut-être passés dans le développement de vos tests! Ceci est une live coding session en Java/Kotlin SpringBoot.

CraftsRecords - L'écosystème des conférences

L'équipe de CraftsRecords vous fait découvrir l'écosystème des conférences en France (et environs), leurs caractéristiques, le calendrier, comment ça se déroule, les formats de talk, les call for papers, etc... Une liste non-exhaustive mais qui vous donnera la big picture du paysage français des conférences tech en France. Une bonne manière d'appréhender cet écosystème du partage de la connaissance lors que l'on veut se lancer en tant que speaker.

JUnit: time to shift into 5th gear!

Did you know that JUnit 5 is almost two years old? However, a large number of Java projects are still tested with JUnit 4, which came out ... 13 years ago! A lot of things have changed since 2006, Java went from 5th to 12th version! Isn't it time to bring our tests up to date? The JUnit team took advantage of this opportunity to completely rethink the framework. Many features have been added or reworked in order to fit with the new paradigms of the Java ecosystem. During this talk, we'll see that even though JUnit 5 introduced many changes, the mechanisms of retro compatibility guarantee an easy and progressive migration.

How to get properly hacked!

Yet another leak of credit card numbers on the internet! https://www.infoq.com/news/2018/11/british-airways-data-breach It is scary isn't it? But wait a minute! What are we doing to make sure our application is actually secured? During this live-coding and live-hacking session, discover the most common mistakes in software developement leading to security vulnerabilities, that the vast majority of us do without even knowing it! After that, you will not see your application in the same way ...

Back in black hat: Comment se faire pogoter (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...

DevRel Salon 2019

JUnit : il serait temps de passer la 5ème !

Saviez-vous que JUnit 5 a déjà plus d’un an ? Pourtant, un grand nombre de projets Java sont encore testés avec JUnit 4, qui est sorti… il y a 13 ans ! Enormément de choses ont évolué depuis 2006, Java a pris 6 versions ! Ne serait-il donc pas temps de remettre nos tests au goût du jour ? L’équipe JUnit a profité de cette 5ème version pour restructurer complètement le framework. De nombreuses features ont été ajoutées ou retravaillées afin de s’adapter aux nouveaux paradigmes de l’écosystème Java. Lors de ce talk, nous verrons que même si tout cela a introduit beaucoup de changements, les mécanismes de rétro et post compatibilité garantissent une migration facile et progressive.

Architecture Hexagonale Level 2 : Comment bien écrire ses tests

De plus en plus d’équipes adoptent l’architecture hexagonale comme structure de prédilection pour leurs applications métiers, mais peu d’entre elles savent réellement bien les tester. Et malheureusement lorsque l’on se plante sur ce point, la maintenance de notre architecture hexa devient un véritable calvaire! Lors de ce talk, nous allons aborder les 5 niveaux de tests préconisés pour les microservices adaptés à l'architecture héxagonale. Et en prime comment avoir une documentation drivée par les tests. Venez découvrir à côté de quoi vous êtes peut-être passés dans le développement de vos tests! Ceci est une live coding session en Java/Kotlin SpringBoot.

Codeurs en Seine 2018 - Détectez et traquez les vulnérabilités qui se cachent dans vos dépendances

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

DevFest Toulouse 2018 - Détectez et traquez les zergs qui se cachent dans vos dépendances

Devoxx 2018 - Developers, you should stop estimating your tasks! #noEstimates

As we all know, estimating is both difficult and expensive and how often your tasks have taken longer than expected? Estimation is today one of the preferred methods for decision-making as well as the evaluation of the release dates of our projects ... but today there is an alternative: no longer estimating our tasks! This talk is feedback on the implementation of #noEstimates on a development team for over a year. You will see what are the keys as well as the tools needed to set it up.

Devoxx 2018 - Find and Track the hidden vulnerabilities inside your dependencies

BDX.IO 2018 - Détectez et traquez les vulnérabilités qui se cachent dans vos dépendances

VoxxedDays Microservices 2018 - Find and Track the hidden vulnerabilities inside your dependencies

BDX.IO 2018 - Développeurs, n'estimez plus vos tâches ! #noEstimates

On le sait tous, estimer est à la fois difficile et coûteux et combien de fois vos tâches ont pris plus de temps que prévues? L'estimation est aujourd'hui l'une des méthodes de prédilection pour la prise de décision ainsi que l'évaluation des dates de release de nos projets... mais aujourd'hui il existe une alternative: ne plus estimer ses tâches! Venez découvrir ce retour d'expérience sur la mise en place du #noEstimates sur une équipe de développement depuis plus d'un an. Vous verrez quelles sont les clés ainsi que les outils nécessaires à sa mise en place.

Devfest Nantes 2018 - Détectez et traquez les aliens qui se cachent dans vos dépendances

Kanban #noEstimates XP