Conception pilotée par le domaine : Introduction

Il y a plusieurs années, un concepteur de logiciels talentueux a ajouté une fonctionnalité d'édition qu'il a appelée « Diviser pour mieux régner » dans un programme de mise en page de journaux très populaire. Cette fonctionnalité était très bien conçue, mais personne ne l'a utilisée. En voici la raison :

1. L'expression « diviser pour mieux régner » n'avait rien à voir avec la mise en page de journaux.
2. Personne ne pouvait décrire en quoi consistait la fonctionnalité ou expliquer pourquoi on l'utilisait.
3. Personne n'a demandé cette fonctionnalité et compte tenu de la situation, personne n'en veut.

En réalité, l'accent a été mis sur ce que l'on pouvait faire avec le programme et non pas sur les raisons pour lesquelles il fallait le faire. 

C'est là qu'intervient la conception pilotée par le domaine (DDD, pour Domain Driven Design en anglais), une approche du développement de logiciels qui vise à appréhender pleinement le domaine dans lequel le logiciel sera appliqué. Lorsque vous maîtrisez le domaine, vous minimisez le risque d'ajouter des fonctionnalités dont vos clients n'ont pas besoin ou dont ils ne veulent pas.

Qu'est-ce que la conception pilotée par le domaine (DDD) ?

Les logiciels sont censés nous faciliter la vie. Ils peuvent rationaliser et automatiser des processus concrets, ou traiter des domaines présentant un intérêt pour des utilisateurs spécifiques. Les aspects traités par les logiciels sont les domaines dans lesquels les logiciels sont censés opérer. Par exemple, le domaine des logiciels de stations de travail audio numériques (DAW) relève du secteur de l'enregistrement audio.  

Un développeur de logiciels nommé Eric Evans a reconnu la nécessité de connaître le domaine des logiciels. Pour introduire l'approche de la DDD, il a écrit un livre intitulé Domain-Driven Design : Tackling Complexity in the Heart of Software (« Conception pilotée par le domaine : faire face à la complexité au cœur des logiciels »). Dans son livre, Evans déclare : « Le cœur des logiciels est leur capacité à résoudre des problèmes liés au domaine pour leur utilisateur. Toutes les autres fonctionnalités, aussi essentielles soient-elles, soutiennent cet objectif fondamental. »

Ainsi, dans notre exemple de mise en page de journaux ci-dessus, vous n'avez pas besoin d'être un professionnel de la mise en page pour concevoir un logiciel de mise en page efficace. Mais vous devez savoir comment les rédacteurs en chef font leur travail si vous voulez créer un logiciel qui réponde à leurs besoins et à leurs méthodes de travail. Toute fonctionnalité complémentaire à ce dont ils ont besoin n'apporte que peu ou pas de valeur ajoutée.

Principes de base de la conception pilotée par le domaine

À la base, la DDD consiste à développer des logiciels qui modélisent des systèmes et des processus du monde réel. L'approche de la DDD repose sur les principes de base suivants :

• Concentrez-vous sur le domaine principal : avant de commencer à coder, parlez avec des personnes qui travaillent dans ce domaine. Ils peuvent vous aider à définir l'ensemble des processus, des procédures et de la terminologie liés à ce domaine. Par exemple, si vous développez des logiciels de gestion des stocks de magasins, parlez aux personnes qui gèrent les stocks des magasins plutôt qu'aux employés des RH ou des finances.
• Limitez la complexité en fondant les conceptions sur des modèles de domaine : lorsque vous maîtrisez le domaine d'activité, créez un modèle qui reflète le domaine du monde réel. Par exemple, votre logiciel de gestion des stocks doit inclure des fonctionnalités importantes pour les gestionnaires de stocks, telles que l'analyse des tendances relatives aux produits, le réapprovisionnement automatique, la lecture des codes-barres, etc. Le modèle est un diagramme, un graphique ou un paragraphe écrit qui représente la structure et le degré d'abstraction des connaissances des spécialistes du domaine.
• Communiquez dans un langage commun : dans son livre, Evans parle de l'importance d'un langage universel. Toutes les personnes impliquées dans le projet doivent utiliser le même langage lorsqu'ils parlent du domaine. Prêtez attention aux mots et aux expressions utilisés par les spécialistes de votre domaine. Adoptez la même terminologie dans votre documentation des exigences, dans le modèle et dans le code lui-même.

Termes clés de la conception pilotée par le domaine

Les termes clés communs suivants sont particulièrement utiles pour se familiariser avec la DDD :

• Logique de domaine : également appelée logique d'entreprise. C'est l'objectif de votre modèle et de la conception du logiciel. La conception est basée sur la logique des règles d'entreprise du monde réel qui sont traduites en code de programmation.
• Modèles de conception : s'il existe un code qui résout un problème similaire à celui sur lequel vous travaillez, adaptez-le à votre cas. N'essayez pas de réinventer la roue à chaque fois.   
• Contexte : paramètre ou environnement qui détermine la signification d'un mot, d'une action ou d'une fonctionnalité dans le domaine du logiciel. Par exemple, dans un certain contexte, il peut être plus judicieux d'utiliser un bouton « Appliquer » plutôt qu'un bouton « Enregistrer ».
• Contexte délimité : les grands projets comportent généralement de nombreux modèles qui doivent être intégrés. Un contexte délimité définit le cadre logique dans lequel un modèle peut évoluer. Cela permet aux autres équipes de savoir ce qu'elles doivent faire pour que leurs modèles soient valides lorsqu'ils sont ajoutés à d'autres.
• Cartographie du contexte : document, graphique ou diagramme qui décrit les relations entre plusieurs contextes délimités. La carte illustre le langage de chaque contexte, son application indépendante et l'interface utilisée pour communiquer avec d'autres contextes délimités.
• Entités : une entité est un objet du domaine qui est défini par son identifiant unique plutôt que par des attributs. Par exemple, une personne achète un ticket pour voir un film. La personne est une entité car l'identifiant unique définit qui elle est, indépendamment des changements de couleur de cheveux, de poids, de taille, etc. 
• Objets de valeur : un objet immuable qui possède des attributs, mais pas d'identité distincte. Par exemple, vous achetez un ticket de cinéma qui ne prévoit pas de siège assigné. Tous les sièges du cinéma sont les mêmes. Les sièges sont fixés par des boulons et ne peuvent pas être déplacés, mais votre ticket vous permet de choisir n'importe quel siège disponible. Dans ce contexte, le siège est un objet de valeur.

Avantages de la conception pilotée par le domaine

L'avantage le plus évident de la DDD est qu'elle permet à tout le monde d'utiliser le même langage. Lorsque les équipes de développement utilisent le même langage que les spécialistes du domaine, cela conduit à une conception de logiciels qui a tout son sens pour l'utilisateur final. Comme la terminologie utilisée dans l'application correspond à des activités du monde réel, le risque de confusion est moindre et les utilisateurs saisissent plus rapidement comment utiliser le produit.

Voici d'autres avantages :

• Les équipes métier et de développement sont alignés : étant donné qu'ils utilisent le même langage, les développeurs communiquent et se comprennent mieux lorsqu'ils échangent avec l'équipe commerciale. Cet alignement réduit le risque de confusion et de malentendu entre l'équipe de développement et les spécialistes du domaine.
• Protège les connaissances du domaine : les connaissances précieuses ne sont pas perdues lorsque les équipes passent à d'autres projets et lorsque de nouvelles personnes sont recrutées pour assurer la continuité des projets existants.
• Plus de flexibilité : les définitions et délimitations du contexte facilitent la gestion des modifications des exigences, car tout le monde a la même perception du domaine d'activité.
• Un suivi simplifié : une meilleure communication et une terminologie commune facilitent le suivi de la mise en œuvre des exigences.
• Meilleur équilibre des applications : on accorde parfois trop d'importance à l'interface utilisateur et à l'interface utilisateur du logiciel. Ces éléments sont importants, mais peuvent entraîner des problèmes si certaines des exigences du domaine sont négligées. La beauté de votre programme n'a aucune importance s'il ne fait pas ce pour quoi les utilisateurs le veulent. Cherchez à répondre aux besoins du domaine et à suivre les recommandations des spécialistes du domaine afin que le logiciel qui en résulte soit équilibré et réponde aux besoins et aux attentes des clients.
• Meilleur code : suivre une approche de la DDD vous donne finalement un code plus clair et plus fiable. Cela peut également permettre d'établir des meilleures pratiques et des modèles de conception reproductibles afin que les projets futurs puissent être traités plus facilement et plus efficacement.

Inconvénients de la conception pilotée par le domaine

La conception pilotée par le domaine présente de nombreux avantages, mais elle ne convient pas nécessairement à tout le monde et à toutes les situations. Voici quelques inconvénients :

• Exige une connaissance approfondie du domaine : vous devez avoir au moins un spécialiste du domaine dans votre équipe. Ce spécialiste doit tout savoir sur le domaine dans lequel le logiciel est censé être appliqué. Sans ces connaissances, vous pourriez vous retrouver avec des fonctionnalités qui ne correspondent pas au contexte du domaine.
• Ne fonctionne que si le domaine est complexe : si le domaine est relativement simple, la DDD pourrait se révéler une perte de temps inutile. Par exemple, le développement d'un logiciel dans un domaine de demande d'emploi peut ne nécessiter que quelques formulaires simples permettant la saisie d'informations personnelles, d'expériences professionnelles antérieures, de références, de contacts en cas d'urgence, etc. Si vous n'avez pas besoin d'un spécialiste en la matière, vous n'avez probablement pas besoin d'une DDD.
• Peut ne pas bien fonctionner en cas de projets hautement techniques : se concentrer sur les domaines d'activité complexes et la logique d'entreprise donne de bons résultats car vous pouvez développer un langage commun entre les développeurs et les spécialistes du domaine. Cependant, lorsque le projet est techniquement complexe, il est difficile d'établir un langage commun qui puisse être compris par les personnes travaillant dans l'entreprise.
• Peut exiger beaucoup de temps : à moins que vos développeurs ne soient déjà des spécialistes du domaine, ils devront passer beaucoup de temps avec l'équipe commerciale afin de bien maitriser le domaine. Mais tout ce temps nécessaire pourrait finalement se muer en avantage quand on aura assimilé toute la connaissance liée au domaine. 

Si votre entreprise souhaite créer des logiciels qui s'intégreront bien dans le domaine d'activité prévu, vous pouvez envisager de mettre en œuvre une DDD. Même si la DDD ne vous convient pas, il convient de la maîtriser car elle peut vous aider à renforcer la communication entre vos équipes de développement et les spécialistes du domaine. Une meilleure communication conduit à une meilleure résolution des problèmes et à des logiciels plus efficaces.