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.