1
J'ai deux agrégats.Logique de domaine - Lire le modèle
Person {
private personID personID;
private nodeID nodeID; //belongs to node
}
Node {
private nodeID nodeID; //node's id
private nodeID parent; //parent node reference by id
public void assign(Person person);
}
Maintenant, j'ai logique de domaine pour ma personne attribuer un service: personne peut être affectée au nœud "X", que s'il appartient au noeud "Y" qui est parent ou grand-père ou grand-grand-père ou .. du noeud "X".
Pour le savoir, je devrais interroger Read Model. Je suis dans le domaine donc je ne peux pas simplement utiliser mon modèle de lecture pour l'interroger. Je ne pense pas que je peux simplement ajouter à mon dépôt, la connexion au modèle de lecture, car il est connecté à mon magasin d'événements. Spécialement, lorsque Read Model peut être placé sur un autre serveur et être une autre application.
Quelle est la bonne façon de l'implémenter?
Le modèle de lecture est juste une abstraction, vous pouvez l'utiliser dans votre domaine. CQRS est un principe de conception de la façon de modéliser un cas d'utilisation métier. Ce n'est pas une règle d'avoir deux compartiments séparés. En fait CQRS est appliqué à un contexte borné dans le sens où des parties du modèle sont utilisées pour changer l'état de l'entreprise (commande) alors que d'autres ne changent rien (requête) – MikeSW
Okey alors. Je comprends, que lire et écrire sont dans le même contexte borné. Mais le problème réside au niveau technique. Je ne peux pas simplement interroger Read Model et y chercher mes agrégats, car une telle chose comme agrégat n'existe pas de ce côté. Read Model contient des données dénormalisées, de sorte que je ne serai pas en mesure de générer un agrégat provenant d'événements. Et que serait responsable de l'interrogation du modèle de lecture, du référentiel? Ou une certaine abstraction, qui en réalité enverrait une requête à l'API REST de Read Model? – Dariss
Vous n'utilisez pas le RM pour interroger les agrégats, juste pour obtenir les données dont vous avez besoin pour une décision d'affaires. Mon opinion est que votre agrégat essaie d'en faire trop, vous ne devriez l'utiliser que pour changer un état de concept, pas pour tout ce qui est lié à un concept. Pour les requêtes métier, vous disposez de services de domaine qui interprètent l'état existant (le modèle lu) en fonction des règles métier. Le but de l'agrégat est simplement de faire respecter les contraintes métier qui maintiennent le concept valide/cohérent, tout autre comportement appartient à un service de domaine. – MikeSW