Confusion sur les contextes limités et les sous-domaines

Question

J'ai lu le livre d'Eric Evan et je lis actuellement celui de Vaughn Vernon. J'en suis au deuxième chapitre, où il parle des sous-domaines et du contexte délimité, et je suis complètement désorienté.

D'après ce que j'ai pu comprendre, il devrait y avoir une relation 1:1 entre un BC et un SD. Cependant, j'ai lu à d'autres endroits que ce n'est pas nécessairement le cas.

Quelqu'un peut-il m'expliquer la relation entre un BC et un SD ?

Answer 1

J'essaie d'expliquer ces concepts avec ma compréhension.

Dans DDD, tout doit être communiqué dans un langage omniprésent afin que l'équipe technique et l'équipe commerciale puissent utiliser les mêmes termes et avoir la même vision des problèmes.

• Domaine dans DDD représentent un réel problème dans les affaires. Par exemple : Le commerce électronique est un domaine, le système de paie est un domaine.
• Le domaine est divisé en plusieurs sous-domaines Ainsi, chaque sous-domaine se concentre sur des problèmes plus petits. Par exemple : Le commerce électronique a de nombreux sous-domaines tels que : Panier d'achat, facturation, catalogue de produits, information client...
• Chaque sous-domaine doit avoir des responsabilités explicites afin d'avoir une frontière pour limiter leurs fonctionnalités, la frontière aidera le sous-domaine à se concentrer sur une seule chose et à la faire bien. Cette limite est considérée comme contexte délimité du sous-domaine. Le contexte délimité sera défini :
  • Combien de modèles de domaine sont nécessaires pour le sous-domaine ?
  • Quelles sont les propriétés nécessaires dans chaque modèle ?
  • Quelles sont les fonctionnalités nécessaires dans le sous-domaine ?

Ex : Le sous-domaine Panier d'achat nécessite des modèles : Panier, Produit, Info client... et contient des fonctions pour effectuer des CRUD sur le panier. Notes : Les modèles de produit et de client dans le sous-domaine Panier d'achat ne sont peut-être pas les mêmes que les modèles dans les sous-domaines Catalogues de produits et Profils de clients, ils contiennent juste les propriétés nécessaires pour afficher le panier d'achat.

Answer 2

Un sous-domaine est une partie de votre entreprise. Il existe des domaines principaux, des domaines de soutien et des domaines génériques. Les domaines principaux sont ceux qui rapportent de l'argent, les domaines de support soutiennent votre activité principale, et les domaines génériques sont ceux dont vous avez besoin, mais dont vous ne vous souciez pas beaucoup, de sorte que vous les achèteriez probablement sur le marché. Pour une compagnie d'assurance, le domaine principal est l'assurance, un domaine de soutien pourrait être le portefeuille de clients et un domaine générique pourrait être quelque chose comme les feuilles de temps.

En général, un contexte délimité est une frontière à l'intérieur de laquelle le langage omniprésent est cohérent. Dans le walhalla DDD, chaque sous-domaine vivrait dans son propre contexte délimité. Dans la réalité cependant, il y a l'héritage, il y a les paquets qui essaient de tout faire en même temps... ce qui forcera toutes sortes de relations maladroites.

Answer 3

Dans son livre "Implementing Domain-Driven Design", Vaughn Vernon affirme que "les sous-domaines vivent dans l'espace du problème et les contextes délimités dans l'espace de la solution".

Imaginez un logiciel qui est développé pour aider un dentiste. Un dentiste a deux problèmes : réparer les dents des patients et prendre des rendez-vous pour les patients. La réparation des dents est le domaine principal et la prise de rendez-vous est un sous-domaine de soutien. Dans le domaine principal, le personnel médical s'intéresse aux antécédents dentaires du patient, s'il peut supporter une anesthésie générale ou non, quel est son problème actuel, etc. Dans le sous-domaine, le personnel (pas nécessairement le personnel médical) s'intéresse aux coordonnées du patient, à la date et à l'heure qui conviennent le mieux au médecin et au patient, au type de soins dentaires nécessaires, etc. Les deux domaines ont besoin d'un modèle de patient, mais ce modèle dépendra du contexte délimité que nous mettons en place pour garantir que les informations et les fonctionnalités correctes sont disponibles lors de la résolution des problèmes de chaque domaine. lire https://robertbasic.com/blog/bounded-contexts-and-subdomains/

Answer 4

Voici ce que je comprends, j'utiliserais l'exemple de l'hôpital pour élaborer les concepts et approfondir les différences entre le CB et le sous-domaine et pourquoi il peut y avoir un cas où il n'y a pas de relation 1:1 entre eux.

Ejemplo

Imaginons que nous réalisons un logiciel pour un hôpital, dans lequel nous avons identifié 3 sous-domaines

• Soins de santé (Domaine principal, où ils veulent réellement guérir le patient)
• Facture (Domaine de soutien axé sur la facturation)
• Connaissances (domaine générique, où les médecins tiennent à jour les procédures sur la façon d'opérer un patient pour une maladie particulière)

Nous savons maintenant que les contextes délimités sont des frontières sous lesquelles les termes ont une signification bien définie. Appliquons-les donc aux sous-domaines

Considérons le terme. Patient . Quelles sont les choses auxquelles vous pensez lorsque vous entendez le terme "patient" ?

1. Leurs symptômes actuels
2. Dossiers médicaux antérieurs
3. Allergies

Et leur crédibilité en matière de paiement de factures ? Le solde impayé actuel ? Vous n'y avez pas pensé ? La raison en est que vous pensiez dans l'espace de sous-domaine principal de Health Care . La crédibilité du paiement des factures n'a de sens que si l'on passe à la Invoice sous-domaine.

Ce que nous comprenons, c'est que le terme "patient" se trouve à l'intérieur d'un contexte délimité, c'est-à-dire une frontière à l'intérieur d'un sous-domaine où il a une signification très spécifique.

La raison pour laquelle il a dit

La CB se situe dans l'espace des solutions/de la mise en œuvre/de la programmation et non dans celui des affaires. d'affaires

car c'est ici que nous décidons des champs et des comportements qui doivent faire partie du modèle du patient.

Dans l'espace du domaine principal, vous pourriez représenter Patient comme ceci

    class Patient {

     List<Allergy> alergies;
     List<MedicalRecord> records;
     Age age;

     boolean isAllergicTo(Allergy allergy)
     boolean canTakeLocalAnesthesia()

    }

Considérant que dans le Invoicing vous pouvez le représenter comme suit

    class Patient {

     CreditCard creditCard;
     CreditScore creditScore;
     Bill currentBill;

     void charge(Amount amount)
    }

De même, le terme Cure dans le sous-domaine "Health Core", les opérations qui ont été/doivent être effectuées sur un patient pour guérir la maladie, tandis que dans le sous-domaine "Health Core", les opérations qui ont été/doivent être effectuées sur un patient pour guérir la maladie. Knowledge subdomain il contiendrait des informations sur les symptômes, les tests de diagnostic, les suggestions de prescription, qui vont de pair avec une maladie.

Vous pouvez maintenant voir que le sous-domaine des soins de santé a plusieurs CB et que sous une CB, chaque terme a une signification très spécifique, ce qui soutient le langage universel.

Answer 5

En relisant 18 fois le Contexte de réservation du livre bleu, j'ai fini par y voir clair. http://codeidol.com/csharp/domain-driven-design/Maintaining-Model-Integrity/Bounded-Context/

Cet article m'a également aidé : http://gorodinski.com/blog/2013/04/29/sub-domains-and-bounded-contexts-in-domain-driven-design-ddd/