Conception pilotée par le domaine

Le concept de conception pilotée par le domaine est bien établi dans la conception de logiciels et de produits numériques. L'article offre une explication simple de DDD, ses principaux termes, ses avantages et ses inconvénients.

Les développeurs ne prêtent toujours pas l'attention nécessaire au concept de conception axée sur le domaine, bien qu'il existe depuis un certain temps.

Ce concept a été développé pour la première fois par Eric Evans dans son livre de 2003 "Domain-Driven Design. Tacking Complexity in the Heart of Software " (dans la communauté des développeurs, on l'appelle le " livre bleu "). L'idée principale de ce livre est qu'un langage unique devrait être une partie fondamentale du produit en cours de création.

La conception pilotée par le domaine est une méthodologie de développement de logiciels permettant de s'attaquer à des projets logiciels complexes afin de livrer un produit final qui répond aux objectifs de l'organisation.

Il existe plusieurs termes communs utiles pour décrire et discuter de la pratique de la DDD :

1. Le concept fondamental est le langage omniprésent

Il favorise une communication transparente entre les participants au projet. L'équipe de développement utilise ce langage dans toutes ses interactions, du cahier des charges au code. Un langage unique est structuré autour du modèle de domaine.

2. Modèle de domaine

Est un résultat de la DDD. Le modèle conceptuel est souvent un dictionnaire et les concepts clés des problèmes du domaine. Décrit les aspects individuels du domaine et peut être utilisé pour résoudre les problèmes liés à ce domaine.

3. Le contexte

La situation dans laquelle apparaît le mot et l'énoncé qui en détermine le sens. Les énoncés modèles ne peuvent être compris que par le contexte.

4. Le contexte délimité

Décrit les limites des sous-systèmes ou le fonctionnement d'un groupe spécifique au sein duquel le modèle est défini et appliqué.

L'objectif principal de DDD est de comprendre comment créer des modèles de domaine abstraits qui peuvent être mis en œuvre avec un ensemble de technologies. La méthodologie DDD fournit des conseils sur la façon de développer des modèles et de développer des technologies pour créer un système qui répond aux besoins des utilisateurs et qui est résilient aux changements dans les domaines.

Comment utiliser DDD?

Le processus de conception pilotée par le domaine prévoit une coopération entre les développeurs et les non-développeurs. Idéalement, il devrait y avoir un modèle commun avec des langages communs, de sorte que lorsque des personnes issues de différents domaines et ayant des perspectives différentes discutent d'une solution, elles disposent d'une base de connaissances commune avec des concepts communs.

Pour appliquer DDD dans la pratique, les développeurs devront partir de zéro. Il ne sera pas possible d'introduire partiellement le concept DDD dans votre projet si le reste du modèle est conçu de manière traditionnelle. Dans ce cas, il ne sera pas possible de satisfaire le résultat final de l'utilisateur.

Avantages de DDD

Facilite la communication

Un langage unique simplifie la communication entre les membres techniques et non techniques de l'équipe de développement.

Améliore la flexibilité

Une conception multi-niveaux et modulaire facilite l'évolution, la modification et la mise à niveau du produit selon les besoins, avec moins de conséquences imprévues.

Efficacité

En cas de participation étroite d'experts dans le domaine concerné, le produit a plus de chances de faire le travail qu'il doit faire. Autrement dit, il est moins probable qu'il ait des fonctions que personne n'utilisera.

Orientation vers l'utilisateur

En gardant le domaine concerné au centre du processus de conception, le résultat est un produit qui répond aux besoins des utilisateurs.

Inconvénients de la DDD

Une connaissance fiable du domaine concerné est nécessaire

Tout développement de produit sera vain si l'équipe ne compte pas au moins un expert du domaine concerné, qui en connaît exactement toutes les subtilités. Et les développeurs devront passer beaucoup de temps avec cet expert pour comprendre parfaitement le domaine concerné.

Ne convient pas aux projets de haute technologie

Si le projet est techniquement difficile à comprendre pour un expert en la matière, tous les membres de l'équipe auront des problèmes à l'avenir.

Dès que l'équipe de développement étudie DDD et commence à appliquer sa philosophie, la perception du logiciel change. En effet, le concept DDD est une approche très puissante et efficace pour développer des projets comportant une logique métier complexe. Pour ce faire, tous les participants doivent avoir un haut degré d'implication dans le projet, être prêts et capables d'étudier le sujet suffisamment en profondeur et de trouver un langage commun.

Littérature pour l'étude de DDD

Il n'existe pas beaucoup de matériel pédagogique sur ce sujet. Toute la théorie n'est décrite que dans quelques livres, et ils sont très difficiles à percevoir.

De nombreuses personnes ayant travaillé sur le concept de DDD vous conseillent de commencer à rechercher les informations sur les DDD dans l'original et dans l'ordre dans lequel elles sont classées ci-dessous:

1. Vaughn Vernon. Implementing Domain-Driven Design.

2. Eric Evans. Domain-Driven Design. Tacking Complexity in the Heart of Software.

3. Vaughn Vernon. Domain-Driven Design. Distilled.

Partagez ceci:

Mots clés:

    Faisons-le ensemble,
    Votre entreprise a une histoire à raconter

    Commande de rappel

    Nous vous rappellerons dans l'heure ou à une heure qui vous convient

    Live Chat
    ×
    Nous utilisons des cookies pour nous assurer que nous vous offrons la meilleure expérience sur notre site Web. Si vous continuez à utiliser ce site, nous supposerons que vous en êtes satisfait.
    Politique de confidentialité