Le pattern MVC, on le connaît tous : c’est souvent la base de nos applications web. Mais quand la logique métier commence à devenir un peu costaude, ça peut vite devenir difficile à maintenir.
Le DDD (Domain-Driven Design), lui, propose de remettre le métier au centre. L’idée, c’est de structurer le code autour des règles métier pour qu’elles soient plus claires, mieux isolées… et surtout plus faciles à faire évoluer.
Pourquoi évoluer vers du DDD ?
Quelques bénéfices qu’on a abordés pendant le workshop :
Un code plus lisible, parce qu’organisé autour du métier
Des règles métier mieux mises en valeur (et moins dispersées partout)
Une base plus solide pour faire évoluer l’application
C’est d’ailleurs complètement en phase avec ce qu’on pousse chez Peaks : du code propre, compréhensible, et qui a vraiment du sens côté métier.
Comment s’y prendre sans tout casser ?
Pas besoin de tout réécrire, et heureusement 😄
On a vu comment avancer progressivement :
- Clarifier l’architecture (Domaine / Application / Infrastructure)
- Extraire la logique métier dans des Value Objects et des Entités
- Mettre en place un Anti-Corruption Layer pour éviter que l’externe vienne “polluer” le domaine
Une approche pragmatique, qu’on applique aussi au quotidien chez Peaks.
MVC vs DDD : faut-il choisir ?
Pas forcément. Les deux peuvent très bien cohabiter :
MVC pour gérer les interactions (controllers, vues)
DDD pour structurer la logique métier
Tout dépend du projet et de ses besoins.
Les conférences
En dehors du workshop, j’ai aussi pu assister aux conférences sur deux jours. Beaucoup de sujets intéressants, entre technique pure et retours d’expérience concrets.
C’est toujours l’occasion de prendre du recul, découvrir de nouvelles idées et repartir avec des choses à tester.
Merci 🙌
Un grand merci à Peaks pour la confiance et l’opportunité de représenter la boîte lors de cet événement.
Et bravo aux équipes du Symfony Live pour l’organisation 👏
Une expérience vraiment top, que ce soit sur le plan technique ou humain.
Laisser un commentaire