Confus au sujet des contextes limités et des sous-domaines
j'ai lu le livre D'Eric Evan et je suis en train de lire le livre de Vaughn Vernon. Je suis dans le deuxième chapitre où il parle de sous-domaines et délimitée contexte et je suis complètement confus maintenant.
D'après ce que j'ai pu distiller, il devrait y avoir une relation 1:1 entre un BC et un SD. Cependant, j'ai lu dans d'autres endroits, ce n'est pas nécessairement le cas.
Quelqu'un peut-il m'expliquer la relation entre un BC et un SD?
3 réponses
un sous-domaine fait partie de vos affaires. Il y a des domaines de base, des domaines de soutien et des domaines génériques. Les domaines de base sont là où se trouve l'argent, les domaines de soutien soutiennent votre activité de base, et les domaines génériques sont ceux dont vous avez besoin, mais ne se soucient pas beaucoup, de sorte que vous les achèteriez probablement de l'étagère. Pour une compagnie d'assurance, le domaine de base est l'assurance, un domaine de soutien pourrait être le portefeuille client, et un domaine générique pourrait être quelque chose comme des feuilles de temps.
dans Généralités un contexte limité est une limite à l'intérieur de laquelle la langue omniprésente est cohérente. Dans DDD walhalla chaque sous-domaine vivrait dans son propre contexte limité. En réalité, cependant, il y a un héritage, il y a des paquets qui essaient de tout faire à la fois... ce qui va forcer toutes sortes de relations maladroites.
j'ai essayer d'expliquer ces concepts avec ma compréhension.
en DDD, tout doit être communiqué dans un langage omniprésent pour 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
- Domaine en DDD représentent un réel problème dans les affaires. Comme: le commerce électronique est un domaine, le système de paie est un domaine
- le domaine est divisé en plusieurs sous-domaines, de sorte que chaque sous-domaines se concentrer des problèmes plus petits. Comme: E commerce a de nombreux sous-domaines tels que: Panier D'achat, facturation, Catalogue de produits, Informations client...
- chaque sous-domaine devrait avoir des responsabilités explicites de sorte qu'il a une limite pour limiter leurs fonctionnalités, la limite aidera le sous-domaine focus à faire seulement une chose et bien faire. Cette limite est considérée comme délimitée contexte du sous-domaine. Le contexte délimité définira:
- combien de modèles de domaines faut - il pour sous-domaine?
- quelles sont les propriétés nécessaires dans chaque modèle?
- quelles fonctionnalités sont nécessaires dans le sous-domaine?
Ex: Panier sous-domaine besoins modèles: le Panier, Produit, informations sur le Client... et contient des fonctions pour effectuer CRUD sur le panier. Notes: Le produit et le modèle client dans le sous-domaine de panier D'achat peut-être pas les mêmes avec les modèles dans les catalogues de produits et les profils clients sous-domaine, ils contiennent juste les propriétés nécessaires l'affichage sur l'écran du Panier d'achat.
relire le contexte de réservation du livre Bleu 18 fois m'a finalement aidé à obtenir un contrôle. http://codeidol.com/csharp/domain-driven-design/Maintaining-Model-Integrity/Bounded-Context/
cet article a aussi aidé: http://gorodinski.com/blog/2013/04/29/sub-domains-and-bounded-contexts-in-domain-driven-design-ddd/