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.
Vous devriez également aimer
Athena, solution serverless d’Amazon, mise en perspective de “Buzz Query”
Nous avions exploré dans l’article précédent les forces et faiblesses de Spark et Elasticsearch. Nous allons à présent creuser en quoi la solution.
Forces et faiblesses de Spark et Elasticsearch
Nous avons partagé les enjeux liés à la techno du Serverless dans le précédent article. Nous allons creuser aujourd’hui les solutions les plus connues dans le domaine du traitement de données à grande échelle, Spark et Elasticsearch.
Le serverless, une approche efficace à bas prix
Nous avions introduit dans l’article précédent ce qu’était la notion de moteur de requête de dashboarding. Nous allons à présent nous concentrer sur une nouvelle notion, plus proche des ressources matérielles, le serverless.