Domain Driven Design
Comment faire face à la complexité grandissante des projets informatiques ? La réalisation des applications modernes nécessitent des équipes toujours plus nombreuses et surtout de nombreux intervenants provenant de différentes sphères de l’entreprise. Les méthodes agiles permettent de prendre en compte la complexité du projet durant la phase de réalisation, mais elles ne résolvent pas nécessairement le problème de la complexité de la communication entre des intervenants provenant de milieux professionnels différents. Le Domain Driven Design, ou Conception Pilotée par le Domaine, peut répondre à cette problématique et s’intègre donc parfaitement à la gestion de projet agile.
L’étape de la conception d’une application ou d’un logiciel est primordiale, est c’est là que le Domain Driven Design entre en jeu. C’est le moment où va être dessinée notre application, où l’on va imaginer ce à quoi elle ressemblera et ce qu’elle fera, et quelles contraintes elle devra respecter. Les choix opérés durant la conception décideront en partie de la qualité finale de l’application. Il faudra prendre en compte des éléments comme la compatibilité avec d’autres applications ou d’autres versions de la même application, ses performances, sa robustesse et sa stabilité ou encore sa sécurité, et bien sûr son coût. Il faudra certainement à ce moment décider des priorités données à tel ou tel critère, car tous ne pourront pas nécessairement être respectés au même moment, tout au long du projet.
C’est également lors de la conception que peuvent être mises en place les méthodes et processus qui garantiront la qualité du code produit, les livrables attendus ou encore les techniques utilisées pour la réalisation de l’application.
La conception est particulièrement importante car les langages de programmation utilisés de nos jours comme PHP, Python, Java, C# ou C++ pour n’en citer que quelques-uns sont tous basés sur les concepts de la programmation orientée objets, ou POO. La transcription des fonctionnalités décrites en programmation orientée objet n’est pas anodin, et demande beaucoup de travail en amont, nécessitant des concepteurs chevronnés, maîtrisant parfaitement les concepts de la POO.
C’est sur cette phase de conception que reposent les futures qualités (ainsi que les défauts) de l’application, comme sa robustesse, son adaptabilité et sa maintenabilité. L’application sera généralement décomposée en modules, dont les fonctionnalités et les responsabilités seront parfaitement identifiées. Ces modules devront être capables de communiquer et de collaborer entre eux, tout en restant indépendants les uns des autres (la disparition d’un module ne doit en aucun cas entraîner la chute de tous les autres).
L’une des principales difficultés est de réussir à faire communiquer efficacement les personnes qui connaissent le métier et peuvent donc décrire les fonctionnalités souhaitées, avec celles ayant les capacités de traduire ces demandes pour qu’elles puissent être transcrites en programmation orientée objet, et surtout que tout le monde se comprenne.
Le Domain Driven Design est apparu pour la première fois en 2003 sous la plume de Cris Evans. Le DDD n’offre pas un cadre de travail spécifique ou une méthode de conception. Il s’agit plutôt d’une approche différente, ayant pour objectif de permettre aux différents intervenants de mieux appréhender la complexité du projet. Pour ce faire, le DDD va permettre de mettre en place une vision commune de l’application, partagée par tous, ainsi qu’un langage commun, pour que tous se comprennent.
La conception de l’application va donc se concentrer sur le cœur du domaine métier et sa logique. Il va être modélisé grâce à une collaboration active entre les experts métiers et les membres de l’équipe de développement qui seront chargés de la réalisation de l’application. Pour faciliter cette collaboration, un langage partagé par tous sera utilisé.
Les experts métiers, tout comme les développeurs, utilisent leur propre langage, adapté à ce qu’ils font. Certains termes peuvent donc désigner des choses différentes d’un groupe à l’autre, et leur utilisation peut conduire à des incompréhensions, dommageables pour la suite du projet. Il faut donc utiliser un langage commun, dissocié de celui du métier comme de celui de l’équipe technique. C’est le modèle du domaine métier qui va servir de référence pour ce langage, qui sera alors utilisé aussi bien à l’oral qu’à l’écrit, dans les documents ou les diagrammes. De cette façon, la communication entre les intervenants sera cohérente et claire. Si des changements doivent intervenir dans le langage au cours du projet, ils devront immédiatement être répercutés dans la conception (nommage des classes d’objets et des méthodes par exemple).
Si l’application reste complexe, son architecture doit absolument permettre de diminuer la complexité de sa maintenance et de son évolution. Le DDD va permettre de séparer complètement le code métier de l’application des autres fonctions, en créant plusieurs couches différentes et en limitant au minimum les dépendances entre elles.
Le DDD va donc proposer quatre couches différentes : le domaine, la présentation, l’application et l’infrastructure.
Le Domain Driven Design permet de se concentrer sur le métier plutôt que sur la technique. La séparation de la logique de l’application en quatre couches distinctes et indépendantes va permettre d’obtenir un domaine totalement indépendant et autonome. Le langage partagé mis en place est là pour s’assurer que les équipes métier et technique soient capables de communiquer efficacement et de se comprendre. Les équipes techniques agiles vont même à terme s’approprier les connaissances métiers, permettant là encore une compréhension facilitée.
N’hésitez pas à utiliser la solution de gestion de projet Nutcache, qui vous permet de prendre en compte la phase de Domain Driven Design facilement. Vous avez la possibilité d’essayer gratuitement Nutcache pour une durée de 14 jours.
Smart & simple all-in-one
Agile project management tool for your business.
© 2018 Nutcache. All rights reserved.
Domain Driven Design
Research & References of Domain Driven Design|A&C Accounting And Tax Services
Source
0 Comments
Trackbacks/Pingbacks