Concevoir en DDD - ou comment piloter le développement business de son application

L’avènement des solutions de déploiements d’application (Docker, Kubernetes, etc.) associées aux solutions d’hébergements en Cloud, incite à la transformation digitale des systèmes informatiques encore basés sur une architecture monolithe vers une architecture en microservices.
Dans de nombreux cas, cette transformation peut s’opérer en suivant une approche DDD (Domain-Driven Design) ou conception orientée domaine.

L'architecture en couches

Pour concevoir une application logicielle moderne, il faut souvent la structurer en quatre composants, aussi appelés couches conceptuelles :
– Interface utilisateur
– Application
– Domaine (DDD)
– Infrastructure
Eric Evans (expert en Technologies, MIT) introduit le concept DDD au début des années 2000

Enrichir la compréhension du besoin métier dans le code

Cette approche est essentiellement motivée par les besoins métiers du produit à développer. Les principes qui en découlent :

une terminologie commune entre le métier, les utilisateurs finaux, les concepteurs et les développeurs, autrement appelé « ubiquitous language »

> Bénéfices :

interprétation optimale des exigences métier,

des API claires,

le front-end et back-end en adéquation

une représentation logique basée sur un modèle de domaine dans le but de fournir une vue riche et visuelle du domaine en utilisant le langage métier

> Bénéfices :

les entités métier et leurs relations sont clairement identifiées,

permettant ainsi de modéliser fidèlement le comportement de l’application

l’implémentation fonctionnelle des artéfacts métier en objets informatiques correspondant

> Bénéfices :

communication métier-utilisateurs-développeurs efficace,

découplage fonctionnel améliorant la maintenabilité,

représentation sous forme de diagrammes de type UML comprise à tout niveau

Contre-indications, mises en garde et limitations

La démarche DDD a un coût, qui exige une réflexion au préalable avant de la mettre en place, cela nécessite :
– Maitrise suffisante des concepts d’Architecture logicielle
– Temps/budget en début de projet
– Structure projet solide (organisation d’entreprise, staffing …)
– Application suffisamment complexe et sensible pour être profitable

Quelques conseils pour profiter des atouts de la DDD :

Le modèle de domaine par et pour tous : il doit être créé et détenu conjointement par toutes les parties du projet (chefs de produit, concepteurs, ingénieurs, utilisateurs, BA, etc.).
L’agilité est l’allier du DDD : mettre en place un processus itératif pour établir le modèle de domaine est fortement recommandé
DDD et BDD sont complémentaires : la conception pilotée par le comportement (BDD) se concentre davantage sur le comportement des entités qui sont modélisées par la DDD.

Conclusion

Au même titre que pour la conception d’une application from scratch, l’approche DDD est idéale pour transformer un produit monolithe en micro-services tant que ces derniers restent de taille raisonnable (ni trop petits pour éviter le « surcodage », ni trop gros pour obtenir découpage métier cohérent). Dans ce dernier cas, la logique métier étant connue, reprendre la conception d’un produit avec la DDD donne l’occasion de corriger les défauts stratégiques, tactiques, comportementaux et ainsi contribue à la rationalisation du produit en améliorant son utilisabilité, sa robustesse et sa maintenabilité.
Enfin, l’approche DDD s’inscrit parfaitement dans un projet Agile : c’est un processus itératif, elle favorise la collaboration entre les différents acteurs en levant les silos.