La conception d’une solution, qu’elle soit pour un site web ou une application mobile, nécessite l’intervention de nombreuses parties prenantes (commercial, marketing, développeur, client final, etc), apportant tous leurs objectifs et leurs expertises. C’est là que le Domain Design Driven (DDD) intervient. Pensée par Eric Evans dans son ouvrage Domain Design Driven, conception pilotée par le domaine, cette méthodologie est au cœur de la conception de beaucoup de solutions, permettant à toutes les parties de se concentrer sur le même objectif : le métier.
Qu’est-ce que le Domain Driven Design ?
“Le Domain Design Driven, c’est mettre le métier au cœur des préoccupations des développeurs”.
– Julien Loison, Lead Développeur chez Dedi
Plus qu’une méthode de travail, le DDD (domain driven design) est une logique de conception qui renforce la compréhension du métier auprès des développeurs, et qui le place donc avant les problématiques techniques. La communication entre les équipes métiers et les équipes de développement est construite autour d’une compréhension et d’une méthode commune au cœur desquelles naît la valeur à créer pour le client. L’objectif premier est de construire une solution à partir de la valeur ajoutée du client, du métier et en limitant l’impact des contraintes techniques. Le besoin métier est au cœur du système.
Quels sont les enjeux du DDD pour mon projet ?
Le DDD présente de nombreux enjeux pour la conception de votre solution e-commerce. Etant centrés sur le métier, les besoins sont mieux pris en compte, livrant des solutions beaucoup plus justes et pertinentes.
Les enjeux du DDD
Centré sur le métier
Comme expliqué plus haut, la construction de la solution suit une logique d’experts métier. L’environnement et les problématiques techniques des équipes de développement passent au second plan pour se concentrer sur une solution qui répondra à tous les enjeux métiers, quels qu’ils soient.
Lire aussi | Sylius, le framework e-commerce entièrement personnalisable.
Langage commun unifié
Pour s’assurer de la compréhension du métier par les équipes de développement, mais aussi de la compréhension de la technique par les équipes expertes métier, un langage commun est créé en début de projet. Chaque therme est bâti pour être compris des deux parties et sera utilisé tout au long du projet pour signifier la même chose. Ce langage est appelé Ubiquitous. Il est aussi conseillé de familiariser les développeurs au métier afin d’éviter toute incompréhension.
Gestion de projet
Le DDD est une manière de penser, un concept se rapprochant des méthodes de travail agiles. L’organisation du projet doit accorder un soin particulier à la communication et l’échange, en plaçant les besoins des utilisateurs finaux au cœur des préoccupations. Le projet se concentre autour de plusieurs objectifs :
- La satisfaction client
- La coopération entre les équipes
- La responsabilisation des équipes
Transmission de l’information
Cela va de pair avec la gestion de projet. Grâce à la création d’un langage commun, l’information est mieux transmise, évitant les erreurs de compréhension entre les équipes et la perte de temps sur des ajustements techniques. Une application qui respecte les principes du DDD donne plus facilement accès aux logiques métier qui la régissent, sans que les considérations purement techniques n’interviennent. C’est donc un avantage sur le long terme, pour garder l’information accessible et transparente, quel que soit l’intervenant impliqué.
Lire aussi | Méthode UX : l’importance de la phase d’exploration pour construire une expérience utilisateur réussie !
Adéquation entre la demande et le produit livré
L’information étant mieux transmise, le produit livré se rapproche finalement au plus près de la demande. La solution répond aux attentes métiers et donc aux utilisateurs finaux.
Maintenance de la solution
La solution est plus facilement maintenable que ce soit d’un point de vue technique ou métier, puisqu’elle a été co-construite sur les mêmes bases. Cela évite de se retrouver face à des projets où l’expert métier est complètement dépendant des développeurs et perd du temps à expliquer les évolutions qu’il souhaite apporter. Ici, tous deux parlent le même langage : gain de temps et de pertinence dans les améliorations.
Chez Dedi
Bien que centré sur le métier, le DDD repose sur certains concepts techniques, appelés pattern, qui consistent à isoler le code dit “métier” du code “technique”. Cela permet une compréhension plus aisée du code par un nouveau développeur sur le projet et donc une meilleure maintenabilité dans le temps. Le code “métier” étant complétement isolé des problématiques techniques, une évolution du socle technique n’aura pas de répercussions sur les règles métiers.
Sylius nous offre un socle technique et fonctionnel de base suffisamment flexible et complet pour que nous puissions nous concentrer au maximum sur les questions métiers. Ce socle nous permet d’appliquer la logique DDD et de la perfectionner au fil des projets.
Vous souhaitez un partenaire centré sur le métier pour votre site web ?
