Le DDD (Domain Driven Design) aussi appelé « la conception pilotée par le domaine » est une approche de conception très populaire au sein de la communauté des software craftsmanship. Nous allons voir de façon général ce qu’est DDD (Domain Driven Design) dans cet article.
Cette communauté a d’ailleurs écrit son propre manisfeste basé sur le manifeste agile que vous pouvez retrouver dans un précédent article que nous avons écrit sur ce blog.
Article : Le manifeste du Software Craftsmanship
Qu’est-ce le DDD (Domain Driven Design) ?
Le DDD (Domain Driven Design) est à la base un livre écrit par Eric Evans en 2003 ; vous pouvez le trouver facilement sur différents revendeurs.
Celui-ci décrit une approche de conception de logiciels basée sur deux principes :
- les conceptions métiers complexes doivent se baser sur un modèle de domaine.
- on privilégie le domaine et la logique liée et non les contraintes techniques.
Cette approche DDD (Domain Driven Design) ne vous dira pas comment « coder » votre application mais vous amènera à une conception de celle-ci à être le reflet des règles métiers.
Ce qu’apporte le DDD (Domain Driven Design) ?
Nous sommes toujours dans cette approche générale de rapprocher tous les acteurs de conception du produit en cassant les silos entre les différentes expertises ; en effet, c’est une approche qui va dans la continuité de l’agilité.
Voici quelques avantages précieux que cette approche DDD (Domain Driven Design) apporte :
- effacer toute ambiguïté possible entre métiers et équipe de réalisation
- conception logicielle privilégiant des adaptations futures simplifiées
- régressions possibles en baisse
Il faut bien comprendre qu’il est indispensable que toutes les différentes compétences (métiers, développeurs…) doivent travailler ensemble dans cette approche DDD (Domain Driven Design).
Quelques grandes entreprises se vantent d’avoir mis cette approche en place… Mais peu l’applique réellement. Et cela n’est pas à cause de la méthode mais de l’état d’esprit encore peu agile.
Quelques concepts clé du DDD (Domain Driven Design)
1/ Bounded Context
Le DDD (Domain Driven Design) propose de découper le contexte global en petits contextes logiques. L’approche insiste sur la mise en place des bornes pour travailler sur des contextes différents. Chaque contexte ne devra pas s’inquiéter de ce qui est à l’extérieur et ne devra pas prévoir pour le futur ; nous répondons à la problématique d’aujourd’hui…
2/ Ubiquitous Language
En utilisant les user-stories, les équipes de développement utilisent au possible un langage commun compris de tous. L’ubiquitous language proposé par DDD (Domain Driven Design) approfondi ce concept en expliquant que les termes utilisés doivent être les mêmes pour tous les experts qu’ils soient fonctionnels ou techniques.
Certains préconisent même de mettre en place un wiki pour valider ces différents termes ; cela peut permettre également à aider les futurs experts qui rejoindront le projet.
Cette étape est très importante car ce langage sera celui qui sera utilisé sur tous les supports : documentation, user stories, code informatique.
3/ Modélisation des domaines
Le DDD (Domain Driven Design) propose dans son approche différentes notions pour modéliser les domaines. Voici quelques exemples :
- aggregate roots : objets représentant quelque chose de concret comme « un client », « une fiche produit »…
- services du domaine : action liant plusieurs aggregate roots ensemble comme « ajouter au panier » qui nécessite le client et la fiche produit
- repositories : abstraction du stockage et de la récupération des Aggregates
- specifications : contient les règles métiers et les critères associés
- évènements du domaine : enregistre des évènements passés et qui peut informer d’autres parties du domaines.
Je ne vais pas rentrer plus dans le détail sur DDD (Domain Driven Design) au sein de cet article ; cependant si vous êtes intéressé pour que j’approfondisse ce sujet de DDD (Domain Driven Design), laissez moi un commentaire.
Vous pouvez comprendre à présent que le DDD (Domain Driven Design) vous guide dans la conception ; elle ne vous dit pas comment coder mais vous montre la voix pour que la conception soit plus proche des besoins métiers.
Cette harmonisation avec DDD (Domain Driven Design) a pour objectif d’avoir une application beaucoup plus simple à faire évoluer.
Lien utile autour de DDD : devops sur blog anglais
Soyez le premier à commenter