Confus au sujet des contextes bornés et des sous-domaines
J'ai lu le livre d'Eric Evan et je lis maintenant le livre de Vaughn Vernon. Je suis dans le deuxième chapitre où il parle de sous-domaines et de contextes délimités.
D'après ce que j'ai pu extraire, il devrait exister une relation 1: 1 entre un BC et un SD. Cependant, j'ai lu dans d'autres endroits que ce n'était pas nécessairement le cas.
Quelqu'un peut-il m'expliquer la relation entre un C.-B. et le SD?
Un sous-domaine fait partie de votre entreprise. Il existe des domaines principaux, des domaines de support et des domaines génériques. Les domaines de base sont la source de l'argent, les domaines de support soutiennent votre activité principale et les domaines génériques sont ceux dont vous avez besoin, mais vous en voulez bien, alors vous les achèteriez probablement sur l'étagère. Pour une compagnie d’assurance, le domaine principal est l’assurance, un domaine de support peut être un portefeuille de clients et un domaine générique peut être quelque chose comme des feuilles de temps.
En général, un contexte délimité est une limite à l'intérieur de laquelle le langage omniprésent est cohérent. Dans DDD walhalla, chaque sous-domaine vivrait dans son propre contexte. En réalité, cependant, il existe un héritage, il y a des paquets qui essaient de tout faire en même temps ... ce qui forcera toutes sortes de relations difficiles.
J'essaie d'expliquer ces concepts avec ma compréhension.
Dans DDD, tout doit être communiqué sous un langage omniprésent afin que l'équipe technique et l'équipe commerciale puissent utiliser les mêmes termes et avoir les mêmes points de vue sur les problèmes.
- Domain dans DDD représente un problème réel dans les affaires. Tels que: le commerce électronique est un domaine, le système de paie est un domaine
- Le domaine est divisé en plusieurs domaines sous-domaines, de sorte que chaque sous-domaine se concentre sur des problèmes plus petits. Tels que: Le commerce électronique comporte de nombreux sous-domaines tels que: panier d'achat, facturation, catalogue de produits, informations client ...
- Chaque sous-domaine doit avoir des responsabilités explicites, de sorte qu'il a une limite pour limiter ses fonctionnalités. La limite aidera le focus du sous-domaine à ne faire qu'une chose et à bien se comporter. Cette limite est considérée comme étant le contexte bounded du sous-domaine. Le contexte délimité définira:
- Combien de modèles de domaine sont nécessaires pour le sous-domaine?
- Quelles propriétés sont nécessaires dans chaque modèle?
- Quelles fonctionnalités nécessaires dans le sous-domaine?
Ex: le sous-domaine Panier nécessite des modèles: Panier, Produit, Informations client ... et contient des fonctions permettant d'exécuter CRUD sur le panier. Remarques: Les modèles Produit et Client du sous-domaine Panier ne sont peut-être pas identiques aux modèles des sous-domaines Catalogues de produits et Profils client. Ils contiennent simplement les propriétés nécessaires à afficher dans le panier.
Relire 18 fois le contexte de réservation à partir du livre bleu m'a enfin aidé à comprendre. http://codeidol.com/csharp/domain-driven-design/Maintaining-Model-Integrity/Bounded-Context/
Cet article a également aidé: http://gorodinski.com/blog/2013/04/29/sub-domains-and-bounded-contexts-in-domain-driven-design-ddd/
Veuillez cocher ceci le lien vous aidera, Contexte ou contexte délimité? Le terme contexte est une description générale d’un groupe de concepts, le terme contexte délimité est plus spécifique - un contexte délimité est un La zone de votre application qui a des limites explicites, a son propre modèle, a son propre modèle et gère son propre code. Dans le contexte borné, tout doit être strictement cohérent.
Habituellement, nous pouvons utiliser les termes Contexte et Contexte limité de manière interchangeable, bien que j'aie tendance à parler de contexte à propos du côté commercial des choses et de terme à contexte technique à la mise en œuvre.