Vous voudrez peut-être afficher le niveau d'inventaire sur la page Web, ou vous pouvez afficher le numéro d'édition de l'inventaire en stock (imaginez que votre inventaire est des livres, des magazines, etc.). Ces informations proviennent du domaine d'inventaire.
La principale chose à noter à ce stade est que vous parlez d'une vue, c'est-à-dire que l'utilisation de données périmées est acceptable.
Cela étant dit, vous n'avez pas besoin d'interagir avec les agrégats (qui sont responsables d'empêcher les modifications de violer l'invariant métier), mais avec une représentation d'une copie récente de l'état de l'agrégat.
Donc, ce que j'attendrais normalement, c'est une requête exécutée sur le catalogue de produits et une autre sur l'inventaire, et quelque chose pour composer les deux dans le DTO dont vous avez besoin pour prendre en charge la vue.
Charger à la fois le domaine du produit et les agrégats du domaine d'inventaire?
C'est donc proche . Nous n'avons pas besoin de charger les agrégats, car nous n'allons rien changer. Mais nous avons besoin de leur état; afin que nous puissions charger cela. Cela dit, je m'attendrais normalement à ce que les deux domaines s'exécutent dans des processus différents. Par conséquent, nous appellerions les deux, pas les chargerons tous les deux.
Souhaitez-vous conserver certaines propriétés sur votre entité de domaine de produit pour le nombre en stock et l'édition en stock, puis utiliser les événements de domaine pour les mettre à jour lorsque l'entité d'inventaire est mise à jour?
"Ne traversez pas les ruisseaux. Ce serait mauvais."
Utiliser des événements pour coordonner les informations entre les contextes de domaine: excellente idée. Pousser des concepts qui appartiennent à un domaine dans un autre: à l'opposé d'une grande idée, sauf plus.
Vous voulez garder les domaines propres. Les applications qui interagissent avec les domaines, ce n'est pas si important. Ainsi, par exemple, il est raisonnable que l'application d'inventaire appelle un service dans l'application de produit pour interroger certains concepts spécifiques au produit à ajouter à une vue. Ou vice versa.
Je ne connais aucune raison pour laquelle une seule application doit être limitée à un seul domaine. Tant qu'il n'y a qu'une seule source de vérité, vous pouvez répartir les transactions comme bon vous semble.
Mais juste pour y réfléchir, dans l'exemple ci-dessus, nous nous retrouverions avec potentiellement 2 tables DB pour le catalogue de produits et l'inventaire des produits. Maintenant, utilisons-nous le même identifiant dans ces derniers car c'est le même produit.
Ce serait la manière la plus simple. En termes plus larges, vous utilisez le même identifiant car l'entité réelle est la même; les deux contextes bornés différents modélisent cette entité différemment, mais le modèle n'est pas l'entité du monde réel.
Lorsque cela ne fonctionne pas, vous aurez besoin d'une requête à utiliser pour combler l'écart. Je pense que la variation la plus courante de cela est que l'entité plus récente préserve l'id de l'entité plus ancienne. Vous le verrez également dans un seul pays de la Colombie-Britannique: les candidats, lorsqu'ils sont approuvés, deviennent des clients. Il s'agit d'un agrégat différent (l'état associé à un client est soumis à un invariant différent de celui du demandeur); donc si votre couche de persistance utilise des flux d'événements, le flux du nouvel agrégat aura besoin d'un identifiant différent. Il y aura donc un peu d'état quelque part qui dit "ce demandeur est devenu ce client".
Ou, pourrions-nous utiliser 1 table et 1 ligne de table pour les données et simplement mapper les données pertinentes sur les propriétés d'agrégation?
OUI! Non, ne fais pas ça. Vous ajoutez un conflit d'opération sans aucune raison commerciale de le faire.
Je pense que votre question appelle vraiment 2 ensembles d'options orthogonales -
Chargez-vous deux objets et présentez-vous leurs données ensemble ou chargez-vous 1 objet contenant tout ce que vous voulez?
Utilisez-vous des agrégats pour afficher des éléments, ou autre chose?
Si vous croyez en l'approche CQRS, il s'avère que les agrégats peuvent ne pas être le meilleur pari pour les lectures. Chaque fois que vous chargez un agrégat, que ce soit pour afficher ses données ou les modifier, vous ajoutez de la concurrence et des conflits à votre système. De plus, les agrégats sont potentiellement plus volumineux et plus lents à charger que si vous utilisez des modèles de lecture ad hoc adaptés à l'affichage.
La solution a) de votre Q semble sujette à beaucoup de ces pièges. L'option b) peut être valide, mais je ne l'utiliserais que si des données du
InventoryManagementBC sont nécessaires pour appliquer des invariants lors de la mutation de l'Productagrégat. Il est préférable qu'un agrégat contienne toutes les données nécessaires pour vérifier ses règles métier lors de la modification, mais du côté lecture, il peut s'asseoir n'importe où.En ce qui concerne les données, une recommandation courante est de donner aux contextes délimités leur propre base de données (pour des raisons de déployabilité et de SoC). Vous devrez probablement utiliser les mêmes identifiants si vous souhaitez faire correspondre les produits entre les deux BC.
À propos des interactions entre BC, vous pouvez également consulter /programming/16713041/communicating-between-two-bounded-contexts-in-ddd
la source
DDD est destiné aux applications où la logique métier est complexe. «imprimer quelque chose» n'est pas une logique métier complexe. Ce n'est en fait pas du tout une logique métier.
Si, la logique métier dans un contexte a besoin d'informations pour gérer correctement certains cas d'utilisation, alors ces informations font partie de ce contexte. Ainsi, l'idée qu'un contexte borné puisse avoir besoin d'informations disponibles dans différents contextes bornés n'a pas de sens, car le contexte borné contient toutes les informations dont il a besoin.
la source
De mon point de vue, il existe différentes définitions de «Produit» - chaque contexte de délimitation a sa propre définition du «produit» - domaine:
En plus de cela, j'ajouterais un contexte de magasinage supplémentaire avec sa propre définition de produit (une combinaison pertinente des domaines de produits des autres contextes de délimitation).
Un produit de boutique aurait «une image et un texte de description» du contenu et de la disponibilité de «l'inventaire» mais pas du «vendeur de produits» de l'inventaire.
Ce contexte de magasinage supplémentaire dépend du contenu, du stock et du prix du contexte de magasinage.
la source