CQRS - dépendances autorisées pour construire le modèle de lecture en utilisant des événements et d'autres sources d'information

Question

Ma question concerne la CQRS (Command and Query Responsibility Segregation) et le mécanisme qui construit le modèle de lecture (views). Autant que je comprends, le modèle de lecture est construit par les gestionnaires d'événements. Ces gestionnaires (également appelés dénormaliseurs) reçoivent des événements de domaine et utilisent ces événements pour générer différentes vues de données.

Un événement spécifique contient des informations sur les modifications effectuées dans le modèle de domaine. Je pense que cette information ne suffit pas dans certains cas, de construire vue - à savoir pas les champs modifiés, pas des entités modifiées sont portées disparues dans ce cas, etc. Ma question

est:

Est-il permis que denormalizer responsable de la modèle de lecture de bâtiment accède non seulement des événements mais aussi:

1. entité modifiée référencés directement dans l'événement?
2. a modifié la racine agrégée et toute entité liée à cet agrégat?
3. une entité est-elle extraite du référentiel?
4. une vue?

Quelle est votre opinion sur les dépendances autorisées pour les gestionnaires d'événements (denormalizers)?

edit: Juste ajouté exemple simple à la question ci-dessus:

Supposons que le modèle suivant:

AR: ProductOffering * Nom * Description * Catégorie * Prix

AR: Client * nom * type * méthode: purchaseProduct (productOffering) qui émet ProductPurchasedByCustomer même t

entité: ProductInstance * client * productOffering

événement

: ProductPurchasedByCustomer * customerId * productOfferingId

Vue: ProductInventoryView * customerId * productOfferingId * CustomerType * productOfferingName * productOfferingCategory * prix

Comment générer ProductInventoryView en utilisant uniquement l'événement ProductPurchasedByCustomer? Comment puis-je écrire denormalizer pour afficher des informations sur customerType, productOfferingName etc? Dois-je rechercher des informations supplémentaires sur customerType et productOfferingName à partir de différentes vues?

Answer 1

Selon ma compréhension:

entité modifiée directement référencée dans l'événement?

pas

changé racine globale et toute entité liée à cet agrégat?

pas

toute entité extraite de domaine du dépôt?

pas

tout rapport qui ne se rapporte à l'événement

pas

entité modifiée rapport pour l'entité qui est référencée directement dans l'événement?

oui

changé racine globale rapport et toute entité rapport liées aux agrégats fait référence à l'événement?

oui

---

parce denormalizer est censé ne rien savoir au sujet du référentiel de domaine et mettre à jour les rapports liés uniquement.

S'il semble que le rapport ne soit pas lié mais qu'il doive être mis à jour, c'est une odeur de code - probable Vous concevez votre modèle/rapports incorrectement.

Answer 2

Si un consommateur d'événements a besoin de plus d'informations, il est acceptable qu'un producteur d'événements fournisse les informations requises, même si elles n'ont pas changé. Eventsourcing ne devrait pas être traité comme un ORM. Rappelez-vous que les choses peuvent devenir difficiles en ce qui concerne la façon dont vous obtenez cette information, mais ne complique pas les choses (pour l'instant). Les gestionnaires d'événement peuvent utiliser l'état (données) du modèle lu s'il n'est pas fourni par l'événement. Mais pour ce faire, vous devez savoir si et quelles données vous pouvez utiliser. Cela vous oblige à coupler le temps aux données. Les messages/événements sont susceptibles d'être traités dans le désordre. Ainsi, fournir des informations dans l'événement, se rapportant à l'événement, est beaucoup plus facile. Essayez de le faire avant de faire quoi que ce soit d'autre. N'essayez pas d'accéder à votre domaine à partir des gestionnaires d'événements spécifiques à votre modèle de lecture, c'est juste un mauvais couplage. Une dernière chose, les agrégats peuvent copier les données d'autres agrégats pour fournir les données dont vous avez besoin dans vos événements. Rappelez-vous que dès lors vous devrez commencer à réfléchir à la façon de conserver ces données dans les agrégats qui les ont copiées en premier lieu. Probablement vous a troublé un peu plus ...