La parole est aux speakers : Arnaud Langlade
Jusqu’à l’AFUP Day 2024, retrouvez nos interviews de speakers pour mieux comprendre leur parcours et le sujet qu’ils ou elles aborderont lors de leur conférence !
La conférence
Symfony, Architecture Hexagonale et CQRSSymfony met à disposition une riche bibliothèque de composants qui permet d'éviter de réinventer la roue. Grâce à Symfony, j'ai pu créer plusieurs applications en me concentrant sur les problématiques métiers plutôt que sur les détails techniques. Cependant, il est essentiel de bien concevoir une application pour garantir une évolution facile et une maintenance aisée. Pendant cette présentation, je vais vous montrer comment j'ai conçu l'architecture de mes applications en utilisant seulement quelques composants Symfony et en appliquant des patterns architecturaux tels que l'architecture hexagonale et le CQRS. |
Cobalt 24/05/2024 10:05-10:45 |
Pentagone ? Octogone ? Étoile ? Le terme « Hexagonale » a-t-il une origine connue pour cette architecture ?
Le nom « architecture hexagonale » vient du fait qu’on utilise un hexagone pour la représenter et l’expliquer mais elle est aussi connue sous le nom de « Ports & Adapters ». J’avoue que quand on m’explique quelque chose avec des images, ça me parle bien plus, et j’aime faire de même quand je dois expliquer quelque chose. Donc, pendant cette présentation, attendez-vous à voir des schémas et des hexagones mais aussi des exemples de code, je vous rassure !
Nos choix ont toujours des conséquences. Pour toi quelles sont les conséquences les plus importantes si on choisit d’implémenter ce type d’architecture ?
L’approche à adopter dépend fortement du contexte. Pour un projet qui se limite à une application CRUD basique, il n’est pas nécessaire d’utiliser l’architecture hexagonale, les patterns du DDD tactique, ou CQRS. Des bundles prêts à l’emploi comme le ResourceBundle de Sylius font parfaitement l’affaire. Par contre, ce n’est pas la même chose lorsqu’on travaille sur une application métier destinée à être maintenue sur le long terme.
Dans ce cas, il vaut mieux découpler le code métier du framework utilisé pour permettre ainsi à chacun d’évoluer indépendamment sans se gêner mutuellement. Il est également préférable de séparer le code métier des entrées/sorties (Input/Output), telles que les interactions avec une base de données. Cette séparation va permettre de tester facilement toutes les parties de l’application. Elle permet de réaliser des tests unitaires sur le code métier tout en vérifiant, via des tests d’intégration, que l’application interagit correctement avec les outils dont elle a besoin.
Et le DDD dans tout ça ?
Le DDD, c’est comme une énorme boîte à outils. Mais lors de cette conférence, on va juste se concentrer sur les patterns tactiques. Ce sont eux qui vont vous aider à modéliser notre code métier. Mais attention ! Ils ne sont utiles que pour des applications métier.
Et si vous vous demandez par où commencer avec le DDD, mon conseil serait super simple : allez échanger avec vos experts métier pour aligner votre compréhension sur la leur. Vous pouvez mettre en place des ateliers comme l’example mapping ou l’event storming pour faciliter ces discussions.
Une conférence présentée par
 Arnaud LANGLADE |
Arnaud est ingénieur logiciel indépendant. Il adore les ateliers tels que l'event storming et l'example mapping, car pour lui, comprendre le problème qu'il cherche à résoudre est essentiel. Il aime tout ce qui se termine par *DD (DDD, BDD et TDD), ces outils et toutes les valeurs d'eXtreme Programming l'ont aidé à développer et à maintenir des applications au cours de ces années. |