Pour la résolution des problèmes complexes, les développeurs optent pour l’approche de la conception pilotée par le domaine. C’est ce qu’on appelle encore le Domain Driven Design (DDD). Développer un logiciel à l’aide du DDD offre la possibilité aux utilisateurs de gagner du temps dans la résolution des problèmes auxquels ils sont confrontés. Que signifie donc la conception pilotée par le domaine ou encore le Domain Driven Design ? Découvrez ici un élément de réponse.
Plan de l'article
Conception pilotée par le domaine ou DDD : qu’est-ce que c’est ?
La conception pilotée par le domaine ou encore Domain Driven Design (DDD) est une approche de développement de logiciels axée sur le métier. En effet, l’écriture du code d’un logiciel est faite de sorte que celui-ci réponde à un besoin bien précis.
A lire également : Quel système de vidéosurveillance choisir ?
Pour remplir son rôle intrinsèque, il est important que le métier de l’utilisateur soit pris en compte lors de la conception de l’outil. C’est ce qu’on appelle la conception pilotée par le domaine (métier) ou le Domain Driven Design.
Les origines du Domain Driven Design (DDD) remontent en 2003 où Éric Evans sort un livre intitulé « Domain-Driven Design, Tackling complexity in the Heart of Software ». Pour l’auteur, c’est un livre qui parait après 20 années de pratique de la conception pilotée par le métier au sein d’une communauté de développeurs DDD.
A lire également : Gestes commerciaux opérateur téléphonique : comment faire une demande ?
En résumé, l’auteur défini le Domain Driven Design comme l’ensemble des modalités basées sur le bon sens, sur des principes et des règles visant à mettre le métier des utilisateurs au cœur de la conception des logiciels.
Conception pilotée par le domaine : quels en sont les principes de base ?
Vous l’aurez compris, le Domain Driven Design repose sur un certain nombre de principes.
La conception basée sur le métier principal
Avant l’écriture du code d’un logiciel, il est primordial de discuter avec les experts du corps du métier pour lequel l’outil sera utile. Un développeur qui souhaite écrire le code d’un logiciel dans le domaine de la santé n’est pas pour autant un professionnel de la santé.
Le mieux sera alors de discuter avec des professionnels de la santé. Ces derniers pourront être utiles dans la définition du processus de conception. Ils peuvent également orienter les développeurs dans les terminologies utilisées.
La conception axée sur un modèle de domaine
Un logiciel conçu pour être utilisé dans un corps de métier doit en réalité refléter le métier dans la vraie vie. Cela permet de limiter le niveau de complexité du logiciel. Pour cela, suivant les principes de la conception pilotée par le domaine, il est important de créer un modèle de domaine qui reste fidèle à la vraie vie. Ici, le modèle peut être un paragraphe ou un graphique. Il n’est rien d’autre que le niveau d’abstraction des terminologies du métier.
L’utilisation d’un langage universel (ubiquitous language)
Dans le modèle et dans l’écriture du code, les terminologies utilisées doivent être comprises de tous. En effet, tous les acteurs qui interviennent dans le projet doivent utiliser le même langage et le comprendre : c’est l’ubiquitous language.
C’est l’un des points les plus importants du Domain Driven Design. Grâce à ce type de langage, on fournit un vocabulaire commun au métier et à toute l’équipe technique.
Quelques terminologies relatives au Domain Driven Design
Il existe de nombreuses terminologies qui permettent de se familiariser avec le Domain Driven Design ou DDD.
Les objets de valeur du Domain Driven Design
Lorsque des objets décrivent des caractéristiques sans avoir une identité distincte, on les appelle les objets de valeurs. Dans le Domain Driven Design, ces objets doivent être immuables pendant leur durée de vie.
Les agrégats
Quand il s’agit de collecter des objets de valeur et des entités, on parle d’agrégats. Le but d’un agrégat est de limiter la violation des invariants.
Le contexte borné ou bounded context
Dans le DDD, il existe une façon de voir le monde : c’est le contexte borné ou bounded context. Un contexte borné est en réalité un concept métier qui, dans son implémentation, répond à une problématique précise. Généralement, les contextes sont rassemblés entre eux même s’ils ne sont pas liés.
Dès lors, il ne s’agira pas de découper l’architecture en fonction du code utilisé, mais plutôt suivant le métier à aborder (le contexte borné).