La conception pilotée par domaine (DDD) est une approche du développement logiciel qui se concentre sur la compréhension et la modélisation du domaine problématique dans lequel un système logiciel fonctionne. Il souligne l’importance de collaborer étroitement avec des experts du domaine pour développer une compréhension approfondie des subtilités et des complexités du domaine. DDD fournit un ensemble de principes, de modèles et de pratiques pour aider les développeurs à capturer et à exprimer efficacement les concepts de domaine dans leurs conceptions logicielles.

Unix contre Windows

Sujets importants pour la conception pilotée par domaine (DDD)

• Qu'est-ce que la conception pilotée par domaine (DDD) ?
• Importance de la connaissance du domaine
• Conception stratégique en conception pilotée par domaine (DDD)
• Modèles de conception tactique dans la conception pilotée par domaine (DDD)
• Avantages de la conception basée sur le domaine (DDD)
• Les défis de la conception pilotée par domaine (DDD)
• Cas d'utilisation de la conception pilotée par domaine (DDD)
• Exemple concret de conception pilotée par domaine (DDD)

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

Domaine

Il fait référence au domaine ou à l'espace de problèmes pour lequel le système logiciel est conçu. Il englobe les concepts, règles et processus du monde réel que le logiciel est censé modéliser ou prendre en charge. Par exemple, dans une application bancaire, le domaine inclut des concepts tels que les comptes, les transactions, les clients et les réglementations liées aux opérations bancaires.

Conduit

Driven implique que la conception du système logiciel est guidée ou influencée par les caractéristiques et les exigences du domaine. En d’autres termes, les décisions de conception reposent sur une compréhension approfondie du domaine, plutôt que d’être motivées uniquement par des considérations techniques ou des détails de mise en œuvre.

Conception

La conception fait référence au processus de création d'un plan ou d'un modèle pour le système logiciel. Cela inclut des décisions sur la manière dont le système sera structuré, sur la manière dont les différents composants interagiront et sur la manière dont le système remplira ses fonctions. fonctionnel et non fonctionnel exigences. Dans le contexte du Domain-Driven Design, l’accent est mis sur la conception du logiciel de manière à refléter avec précision la structure et le comportement du domaine.

Domain-Driven Design est un concept introduit par un programmeur Éric Evans en 2004 dans son livre Conception pilotée par domaine : s'attaquer à la complexité au cœur du logiciel

Importance de la connaissance du domaine

Supposons que nous ayons conçu un logiciel en utilisant toutes les dernières technologies et infrastructures et que notre architecture de conception logicielle soit incroyable, mais lorsque nous publions ce logiciel sur le marché, c'est en fin de compte l'utilisateur final qui décide si notre système est génial ou non. De plus, si le système ne répond pas aux besoins de l’entreprise, il ne sert à rien. Peu importe sa beauté ou la qualité de l'architecture de son infrastructure.

Selon Éric Evans Lorsque nous développons des logiciels, nous ne devons pas nous concentrer principalement sur la technologie, mais plutôt sur les affaires. Souviens-toi,

Ce n’est pas le travail du client de savoir ce qu’il veut – Steve Jobs

Conception stratégique en conception pilotée par domaine (DDD)

La conception stratégique dans la conception pilotée par domaine (DDD) se concentre sur la définition de l'architecture et de la structure globales d'un système logiciel d'une manière qui s'aligne sur le domaine du problème. Il aborde des préoccupations de haut niveau telles que la manière d'organiser les concepts de domaine, de diviser le système en parties gérables et d'établir des limites claires entre les différents composants.

Voyons quelques concepts clés de la conception stratégique dans la conception pilotée par domaine (DDD)

1. Contextes délimités

• Un contexte délimité représente une zone spécifique dans le domaine global du problème où un modèle ou un langage particulier s'applique de manière cohérente.
• Différentes parties d'un système peuvent avoir des significations différentes pour les mêmes termes, et un contexte limité définit des limites explicites à l'intérieur desquelles ces termes ont des significations spécifiques.
• Cela permet aux équipes de développer des modèles adaptés à des contextes spécifiques sans introduire de confusion ou d'incohérences.
• Les contextes délimités aident à gérer la complexité en décomposant un domaine vaste et complexe en parties plus petites et plus faciles à gérer.

2. Cartographie du contexte

• La cartographie du contexte est le processus de définition des relations et des interactions entre différents contextes délimités.
• Cela implique d’identifier les domaines de chevauchement ou d’intégration entre les contextes et d’établir des canaux de communication et des accords entre eux.
• La cartographie contextuelle permet de garantir que les différentes parties du système peuvent collaborer efficacement tout en maintenant des frontières claires entre elles.
• Il existe différents modèles et techniques de cartographie contextuelle, tels que le partenariat, le noyau partagé et le client-fournisseur.

3. Modèles stratégiques

• Les modèles stratégiques sont des lignes directrices ou des principes généraux permettant d'organiser l'architecture d'un système logiciel d'une manière qui s'aligne sur le domaine du problème.
• Ces modèles aident à relever les défis courants liés à la conception de systèmes complexes et fournissent des approches éprouvées pour structurer efficacement le système.
• Des exemples de modèles stratégiques incluent les agrégats, les événements de domaine et la couche anti-corruption.
• Ces modèles fournissent des solutions aux problèmes récurrents de la conception axée sur le domaine et contribuent à garantir que l'architecture du système reflète avec précision les concepts de domaine sous-jacents.

4. Noyau partagé

• Le noyau partagé est un modèle stratégique qui implique d'identifier les domaines communs entre différents contextes délimités et d'établir un sous-ensemble partagé du modèle de domaine utilisé par plusieurs contextes.
• Ce sous-ensemble partagé, ou noyau, facilite la collaboration et l'intégration entre les contextes tout en permettant à chaque contexte de conserver son propre modèle distinct.
• Le noyau partagé doit être utilisé judicieusement, car il introduit des dépendances entre les contextes et peut conduire à un couplage s'il n'est pas géré avec soin.

xd xd signification

5. Couche anti-corruption (ACL)

• La couche anti-corruption est un autre modèle stratégique qui permet de protéger un système de l'influence de systèmes externes ou existants qui utilisent des modèles ou des langages différents.
• Une ACL agit comme une couche de traduction entre le système externe et le modèle de domaine principal, transformant les données et les messages selon les besoins pour garantir la compatibilité.
• Cela permet au modèle de domaine principal de rester pur et concentré sur le domaine problématique, tout en continuant à s'intégrer aux systèmes externes si nécessaire.

6. Langue omniprésente

Le langage omniprésent fait référence à un vocabulaire ou à un langage partagé qui est utilisé de manière cohérente et universelle par toutes les parties prenantes impliquées dans le développement d'un système logiciel. Ce langage se compose de termes, d'expressions et de concepts qui représentent avec précision les connaissances et les concepts du domaine.

Certains des principes clés du langage omniprésent sont :

• Compréhension partagée : L'objectif principal d'Ubiquitous Language est d'établir une compréhension commune du domaine problématique entre tous les membres de l'équipe de développement, y compris les développeurs, les experts du domaine, les analystes commerciaux et les parties prenantes. En utilisant un langage commun, toutes les personnes impliquées peuvent communiquer plus efficacement et transmettre avec plus de précision les concepts et les exigences du domaine.
• Cohérence et clarté : Le langage omniprésent favorise la cohérence et la clarté de la communication en utilisant une terminologie précise et sans ambiguïté. Chaque terme ou expression de la langue doit avoir une signification claire et convenue,
• Alignement avec les concepts commerciaux : Le langage utilisé dans DDD doit s'aligner étroitement sur la terminologie et les concepts utilisés dans le domaine commercial. Il doit refléter la façon dont les experts du domaine pensent et parlent du domaine problématique, garantissant que le logiciel représente avec précision les concepts et les processus du monde réel.
• Nature évolutive : Le langage omniprésent n'est pas statique mais évolue au fil du temps à mesure que l'équipe acquiert une compréhension plus approfondie du domaine et que les exigences changent. Il doit s'adapter pour refléter les nouvelles idées, découvertes ou changements dans les priorités de l'entreprise, garantissant que le langage reste pertinent et à jour tout au long du processus de développement.

Modèles de conception tactique dans la conception pilotée par domaine (DDD)

Dans la conception pilotée par domaine (DDD), les modèles de conception tactiques sont des stratégies ou des techniques spécifiques utilisées pour structurer et organiser le modèle de domaine au sein d'un système logiciel. Ces modèles aident les développeurs à capturer efficacement la complexité du domaine, tout en favorisant la maintenabilité, la flexibilité et l'évolutivité.

Voyons quelques-uns des principaux modèles de conception tactique dans DDD :

1. Entité

Une entité est un objet de domaine qui possède une identité et un cycle de vie distincts. Les entités sont caractérisées par leurs identifiants uniques et leur état mutable. Ils encapsulent le comportement et les données liées à un concept spécifique au sein du domaine.

Par exemple, dans une application bancaire, unBankAccount>l'entité peut avoir des propriétés telles que le numéro de compte, le solde et le propriétaire, ainsi que des méthodes pour déposer, retirer ou transférer des fonds.

2. Objet de valeur

Un objet de valeur est un objet de domaine qui représente une valeur conceptuellement immuable. Contrairement aux entités, les objets de valeur n'ont pas d'identité distincte et sont généralement utilisés pour représenter des attributs ou des propriétés d'entités. Les objets de valeur sont comparables sur le plan de l'égalité en fonction de leurs propriétés plutôt que de leur identité.

Par exemple, unMoney>L'objet de valeur peut représenter un montant spécifique de devise, encapsulant des propriétés telles que le type et le montant de la devise.

3. Agrégat

• Un agrégat est un cluster d'objets de domaine traités comme une seule unité à des fins de cohérence des données et d'intégrité transactionnelle.
• Les agrégats sont constitués d'une ou plusieurs entités et objets de valeur, avec une entité désignée comme racine de l'agrégat.
• La racine de l’agrégat sert de point d’entrée pour accéder et modifier l’état interne de l’agrégat.
• Les agrégats imposent des limites de cohérence au sein du modèle de domaine, garantissant que les modifications apportées aux objets associés sont apportées de manière atomique.

Par exemple, dans un système de commerce électronique, unOrder>l'agrégat peut être constitué d'entités telles queOrderItem>etCustomer>, avec leOrder>entité servant de racine globale.

4. Référentiel

• Un référentiel est un mécanisme permettant d'extraire la logique d'accès aux données et de persistance du modèle de domaine.
• Les référentiels fournissent une interface standardisée pour interroger et stocker les objets de domaine, masquant les détails de la manière dont les données sont récupérées ou stockées. Les référentiels encapsulent la logique de traduction entre les objets de domaine et les mécanismes de stockage de données sous-jacents, tels que les bases de données ou les services externes.
• En dissociant le modèle de domaine des problèmes d'accès aux données, les référentiels permettent une plus grande flexibilité et une plus grande maintenabilité.

Par exemple, unCustomerRepository>peut fournir des méthodes d'interrogation et de stockageCustomer>entités.

5. Usine

• Une usine est un modèle de création utilisé pour encapsuler la logique de création d’instances d’objets de domaine complexes. Les usines résument le processus d'instanciation d'objets, permettant aux clients de créer des objets sans avoir besoin de connaître les détails de leur construction.
• Les usines sont particulièrement utiles pour créer des objets nécessitant une logique d’initialisation complexe ou impliquant plusieurs étapes.

Par exemple, unProductFactory>pourrait être responsable de la création d'instances deProduct>entités avec des configurations par défaut.

6. Prestations

• Un service est un objet de domaine qui représente un comportement ou une opération qui n’appartient naturellement à aucune entité ou objet de valeur spécifique.
• Les services encapsulent la logique de domaine qui opère sur plusieurs objets ou orchestre les interactions entre les objets.
• Les services sont généralement apatrides et se concentrent sur l'exécution de tâches spécifiques ou l'application de règles de domaine.

Par exemple, unOrderService>peut fournir des méthodes pour traiter les commandes, appliquer des remises et calculer les frais d'expédition.

Avantages de la conception basée sur le domaine (DDD)

• Compréhension partagée :
  • Il encourage la collaboration entre les experts du domaine, les développeurs et les parties prenantes.
  • En encourageant une compréhension commune du domaine problématique grâce au langage omniprésent, les équipes peuvent communiquer plus efficacement et garantir que le logiciel reflète fidèlement les besoins et les exigences de l'entreprise.
• Concentrez-vous sur le domaine principal :
  • Il aide les équipes à identifier et à prioriser le domaine principal de l'application, c'est-à-dire les zones du système qui apportent le plus de valeur à l'entreprise. En concentrant les efforts de développement sur le domaine principal, les équipes peuvent fournir des fonctionnalités qui répondent directement aux objectifs commerciaux et différencient le logiciel de ses concurrents.
• Résilience au changement :
  • Il met l'accent sur la conception de systèmes logiciels résilients au changement en modélisant le domaine d'une manière qui reflète les complexités et les incertitudes inhérentes au domaine du problème.
  • En intégrant le changement comme élément naturel du développement logiciel, les équipes peuvent répondre plus efficacement à l’évolution des besoins commerciaux et des conditions du marché.
• Séparation claire des préoccupations :
  • DDD encourage une séparation claire des préoccupations entre la logique de domaine, les problèmes d'infrastructure et les problèmes d'interface utilisateur. En isolant la logique de domaine des détails techniques et des problèmes d'infrastructure, les équipes peuvent maintenir un modèle de domaine propre et ciblé, indépendant des détails de mise en œuvre spécifiques ou des choix technologiques.
• Testabilité améliorée :
  • Il favorise l'utilisation d'objets de domaine avec des limites et des comportements bien définis, ce qui facilite l'écriture de tests meilleurs et ciblés qui vérifient l'exactitude de la logique de domaine.
  • En concevant des systèmes logiciels en gardant à l'esprit la testabilité, les équipes peuvent garantir que les modifications apportées à la base de code sont sûres et prévisibles, réduisant ainsi le risque d'introduction de régressions ou d'effets secondaires involontaires.
• Prise en charge de règles métier complexes :
  • Il fournit des modèles et des techniques pour modéliser et mettre en œuvre des règles métier et des flux de travail complexes au sein du modèle de domaine.
  • En représentant explicitement les règles métier dans le modèle de domaine, les équipes peuvent garantir que le logiciel reflète avec précision les subtilités du domaine métier et applique les contraintes et exigences spécifiques au domaine.
• Alignement avec les objectifs commerciaux :
  • En fin de compte, il vise à aligner les efforts de développement de logiciels sur les buts et objectifs stratégiques de l’entreprise. En se concentrant sur la compréhension et la modélisation du domaine problématique, les équipes peuvent fournir des solutions logicielles qui soutiennent directement les objectifs commerciaux, stimulent l'innovation et créent de la valeur pour les parties prenantes et les utilisateurs finaux.

Les défis de la conception pilotée par domaine (DDD)

• Complexité :
  • DDD peut introduire de la complexité, en particulier dans les domaines vastes et complexes.
  • La modélisation précise de domaines métier complexes nécessite une compréhension approfondie du domaine et peut impliquer de gérer l'ambiguïté et l'incertitude. La gestion efficace de cette complexité nécessite une planification minutieuse, une collaboration et une expertise.
• Adoption linguistique omniprésente :
  • Établir et maintenir un langage omniprésent (un vocabulaire partagé qui représente avec précision les concepts du domaine) peut s'avérer difficile. Cela nécessite une collaboration entre les développeurs et les experts du domaine pour identifier et convenir des termes et significations du domaine.
  • Parvenir à un consensus sur la langue omniprésente peut nécessiter de surmonter les barrières de communication et de concilier les différences de terminologie et de perspectives.
• Alignement du contexte délimité :
  • Dans des domaines vastes et complexes, différentes parties du domaine peuvent avoir des modèles distincts et des contextes délimités. Aligner ces contextes délimités et assurer la cohérence entre eux peut s’avérer difficile.
  • Cela nécessite une communication, une collaboration et une coordination claires entre les équipes travaillant sur différentes parties du domaine pour éviter les incohérences et les conflits.
• Complexité technique :
  • La mise en œuvre efficace des principes et modèles DDD peut nécessiter l’adoption de nouvelles technologies, cadres et approches architecturales. L'intégration de DDD avec des systèmes existants ou des bases de code héritées peut être complexe et nécessiter une refactorisation ou une refonte du code existant pour l'aligner sur les principes DDD.
  • Les défis techniques tels que les performances, l’évolutivité et la maintenabilité doivent être soigneusement abordés pour garantir le succès de l’adoption de DDD.
• Résistance au changement :
  • L’introduction de DDD peut se heurter à la résistance des membres de l’équipe habitués aux approches de développement traditionnelles ou qui perçoivent DDD comme trop complexe ou peu pratique.
  • Vaincre la résistance au changement nécessite une communication, une éducation et un leadership efficaces pour démontrer les avantages du DDD et répondre aux préoccupations et au scepticisme.
• Sur-ingénierie :
  • Il existe un risque de sur-ingénierie lors de l'application de DDD, où les équipes se concentrent trop sur la modélisation de concepts de domaine complexes et sur l'introduction d'abstractions ou de complexité inutiles. Trouver le bon équilibre entre simplicité et expressivité est crucial pour éviter de trop compliquer la conception et la mise en œuvre.

Cas d'utilisation de la conception pilotée par domaine (DDD)

• Finance et banque :
  • Dans le secteur financier, DDD peut être utilisé pour modéliser des instruments financiers, des transactions et des exigences réglementaires complexes. En représentant avec précision les concepts de domaine tels que les comptes, les transactions et les portefeuilles, DDD contribue à garantir l'intégrité et la cohérence des systèmes financiers. Il permet également une meilleure gestion des risques, une meilleure conformité et un meilleur reporting.
• Commerce électronique et vente au détail :
  • Les plateformes de commerce électronique traitent souvent des concepts de domaine complexes tels que les catalogues de produits, la gestion des stocks, la tarification et les commandes des clients. DDD peut aider à modéliser ces concepts efficacement, en activant des fonctionnalités telles que des recommandations personnalisées, une tarification dynamique et un traitement rationalisé des commandes.
• Santé et sciences de la vie :
  • Dans le domaine de la santé, DDD peut être utilisé pour modéliser les dossiers des patients, les diagnostics médicaux, les plans de traitement et les flux de travail des soins de santé. En représentant avec précision des concepts de domaine tels que les données démographiques des patients, les antécédents médicaux et les protocoles cliniques, DDD permet le développement de systèmes robustes de dossiers de santé électroniques (DSE), de plates-formes d'imagerie médicale et d'applications de télémédecine.
• Assurance :
  • Les compagnies d'assurance gèrent divers produits, polices, réclamations et processus de souscription. DDD peut aider à modéliser ces concepts de domaine complexes, en activant des fonctionnalités telles que la gestion des polices, le traitement des réclamations, l'évaluation des risques et l'analyse actuarielle.
• Immobilier et gestion immobilière :
  • La gestion immobilière et immobilière implique la gestion de diverses propriétés, baux, locataires, demandes d'entretien et transactions financières. DDD peut aider à modéliser efficacement ces concepts de domaine, en activant des fonctionnalités telles que les listes de propriétés, la gestion des baux, les portails des locataires et le suivi des actifs.

Exemple concret de conception pilotée par domaine (DDD)

Énoncé du problème

Disons que nous développons une application de covoiturage appelée RideX. Le système permet aux utilisateurs de demander des courses, aux conducteurs d'accepter les demandes de courses et facilite la coordination des courses entre les utilisateurs et les conducteurs.

25 c à k

Langue omniprésente

1. Utilisateur : Désigne les particuliers qui demandent des courses via la plateforme RideX.
2. Conducteur : Désigne les personnes qui proposent des courses aux utilisateurs via la plateforme RideX.
3. Demande de trajet : représente la demande de trajet d'un utilisateur, spécifiant des détails tels que le lieu de prise en charge, la destination et les préférences de trajet.
4. Monter : représente une instance unique d'un trajet, y compris des détails tels que les lieux de prise en charge et de dépose, le tarif et la durée.
5. Statut du trajet : représente l'état actuel d'un trajet, tel que Demandé, Accepté, En cours ou Terminé.

Contextes délimités

1. Contexte de gestion des déplacements : Responsable de la gestion du cycle de vie des courses, y compris les demandes de courses, les affectations de courses aux conducteurs et les mises à jour de l'état des courses.
2. Contexte de gestion des utilisateurs : gère l'authentification des utilisateurs, l'enregistrement et les fonctionnalités spécifiques à l'utilisateur telles que l'historique des courses et les méthodes de paiement.
3. Contexte de gestion des pilotes : gère l'authentification du conducteur, l'enregistrement, l'état de disponibilité et les fonctionnalités spécifiques au conducteur telles que les gains et les notes.

Entités et objets de valeur

1. Entité utilisateur : Représente un utilisateur enregistré de la plateforme RideX, avec des propriétés telles que l'identifiant utilisateur, l'e-mail, le mot de passe et les informations de paiement.
2. Entité pilote : Représente un conducteur enregistré sur la plateforme RideX, avec des propriétés telles que l'identifiant du conducteur, les détails du véhicule et le statut du conducteur.
3. Entité de demande de trajet  : représente la demande de trajet d'un utilisateur, y compris les propriétés telles que l'ID de la demande, le lieu de prise en charge, la destination et les préférences de trajet.
4. Entité de trajet : représente une instance unique d'un trajet, y compris des propriétés telles que l'identifiant du trajet, les lieux de prise en charge et de dépose, le tarif et le statut du trajet.
5. Objet de valeur d'emplacement : Représente un emplacement géographique, avec des propriétés telles que la latitude et la longitude.

Agrégats

1. Agrégat de trajet : se compose de l'entité Ride comme racine globale, ainsi que des entités associées telles que les entités Demande de trajet, Utilisateur et Conducteur. Le Ride Aggregate encapsule la logique de gestion du cycle de vie d'un trajet, y compris la gestion des demandes de trajet, l'affectation des chauffeurs et la mise à jour du statut du trajet.

Dépôt

1. Référentiel de courses : Fournit des méthodes pour interroger et stocker les entités liées au trajet, telles que la récupération des détails du trajet, la mise à jour de l'état du trajet et le stockage des données liées au trajet dans la base de données.

Prestations de service

1. Service d'affectation de trajet : Responsable de l'attribution des chauffeurs disponibles aux demandes de trajet en fonction de facteurs tels que la disponibilité du chauffeur, la proximité du lieu de prise en charge et les préférences de l'utilisateur.
2. Service de paiement : Gère le traitement des paiements pour les trajets terminés, calcule les tarifs, traite les paiements et met à jour les informations de paiement des utilisateurs et des conducteurs.

Événements de domaine

1. Événement RideRequested : Représente un événement déclenché lorsqu'un utilisateur demande un trajet, contenant des informations telles que les détails de la demande de trajet et l'ID utilisateur.
2. Événement RideAccepted : Représente un événement déclenché lorsqu'un conducteur accepte une demande de trajet, contenant des informations telles que l'ID du trajet, l'ID du conducteur et le lieu de prise en charge.

Exemple de scénario

1. Utilisateur demandant un trajet  : un utilisateur demande un trajet en fournissant son lieu de prise en charge, sa destination et ses préférences de trajet. RideX crée une nouvelle entité de demande de trajet et déclenche un RideRequestedEvent.
2. Conducteur acceptant un trajet : Un conducteur accepte une demande de trajet de la plateforme RideX. RideX met à jour le statut du trajet sur Accepté, attribue le conducteur au trajet et déclenche un RideAcceptedEvent.
3. Balade en cours : L'utilisateur et le conducteur coordonnent le trajet, le statut du trajet passant d'Accepté à En cours une fois que le conducteur atteint le lieu de prise en charge.
4. Achèvement du trajet : Une fois la destination atteinte, le statut du trajet est mis à jour sur Terminé. RideX calcule le tarif, traite le paiement et met à jour les informations de paiement de l'utilisateur et du conducteur en conséquence.