Incontestablement, le monde du développement d’applications a connu de profondes mutations ces 10 dernières années, faisant émerger des approches plus agiles et plus en adéquation avec les attentes du marché. Parmi ces évolutions, le Domain Driven Design (DDD) connaît un réel engouement et s’impose comme une approche de conception logicielle fiable et durable. Quelles sont les raisons d’un tel succès ?
Avant de rentrer dans le vif du sujet, revenons d’abord sur la définition même de cette nouvelle approche.
L’approche DDD fournit un ensemble de pratiques, principes et patterns logiciels pour mieux gérer la complexité métier et produire des applications répondant plus précisément aux besoins des utilisateurs, et ce, quel que soit le langage de programmation ou l’environnement technologique utilisés.
Il ne s’agit donc pas ici de proposer une approche technologique nouvelle, mais un modèle de conception permettant aux développeurs et aux directions métiers de se focaliser sur ce qui fait le succès des produits logiciels, tout en gagnant en confort de travail et en productivité.
De manière plus opérationnelle, l’approche DDD favorise l’alignement entre l’espace contenant l’ensemble des connaissances métiers, règles, hypothèses et usages, appelé « espace des problèmes » ; et l’espace contenant les langages, frameworks et outils pour construire techniquement les produits logiciels, appelé « l’espace des solutions ».
1) Utiliser les techniques de collaborative design
Pour atteindre cet alignement, il faut d’abord explorer « l’espace des problèmes » afin de réduire les incompréhensions existantes entre les équipes techniques et les experts métiers
Le principe consiste à fournir des techniques de collaboration (tels que « User Story Mapping », « Event Storming », « Wirhpool Model ») pour extraire les connaissances métiers. Prenant généralement la forme de jeux de facilitations, ces ateliers facilitent l’engagement et permettent d’acquérir un maximum de connaissance métier en un minimum de temps. Un format idéal pour des experts métiers souvent très occupés. A l’issue de ces séances de travail, un unique et même langage entre les différentes équipes émerge, appelé « Ubiquitous Language (UL) ». Composé de termes communs, ce langage sera utilisé dans tous les supports de communication tels que les emails, les diagrammes d’Architecture, la documentation et bien sûr le code source afin de limiter les ambigüités et d’introduire les concepts métiers au sein des produits logiciels.
2) Décomposer l’espace des problèmes pour se focaliser sur ce qui compte
Dans une démarché DDD, on considère que toutes les parties de « l’espace des problèmes » n’ont pas le même niveau de complexité. Pour livrer les produits le rapidement possible, il convient donc de maximiser les efforts sur les parties les plus importantes, en découpant le produit logiciel en sous-domaines et en identifiant ses « Core domain » autrement dit sa raison d’être.
Ce travail d’identification n’est pas aisé. Seule l’expérience et la prise en compte du contexte logiciel (pour quels cas d’usages, pour qui, comment, etc.) aideront à trouver à terme le bon découpage logiciel.
3) La construction de modèles
Ensuite, pour chacun des sous-domaines, seront associés un ou plusieurs modèles dans le but de constituer à terme « l’espace des solutions ».
Cette étape de modélisation consiste à produire une vue représentant les éléments significatifs répondant aux principaux cas d’usages. Pour la mise en œuvre de ces modèles, plusieurs patterns d’implémentation existent et leur sélection dépendra de la complexité et du niveau d’importance de chacun des sous-domaines.
Reste que ces modèles doivent évoluer tout au long de la vie des produits et répondre aux besoins métiers changeants et aux nouveaux cas d’usages.
4) La préservation d’un modèle compréhensible et utile
Pour garder l’intégrité du code et en limiter la complexité, il est enfin nécessaire de décomposer son « espace de solutions » en sous-modèles appelés « Bounded Context » avec des frontières linguistiques explicites. Cette décomposition permet à plusieurs équipes de développement de travailler de manière simultanée et indépendante.
L’approche DDD permet donc de remettre les besoins métiers au cœur des préoccupations du développement logiciel, en renforçant l’alignement entre les équipes techniques et les équipes métiers. Le DDD est avant tout un processus d’apprentissage, d’expérimentation et d’exploration dans le but de produire un modèle logiciel efficace et utile. L’usage de cette approche a donc de beaux jours devant elle et va continuer à se diffuser dans le monde du logiciel.
Grégory Boissinot – CTO et Architecte Logiciel chez SOAT
