2015-07-16 2 views
8

Je suis nouveau au monde CQRS/ES et j'ai une question. Je travaille sur une application web de facturation qui utilise le sourcing d'événements et CQRS. Ma question est la suivante: à ma connaissance, une nouvelle commande arrivant dans le système (disons ChangeLineItemPrice) devrait passer par le modèle de domaine pour être validée comme une commande légale (par exemple, pour vérifier si cet élément de ligne existe réellement, le prix ne viole aucune règle commerciale, etc.). Si tout va bien (la commande n'est pas rejetée) - alors l'événement approprié est créé et stocké (par exemple LineItemPriceChanged)Agrégats CQRS

La chose que je n'ai pas bien comprise est de savoir comment conserver cet agrégat en mémoire pour commencer, avant d'essayer d'appliquer la commande. Si j'ai un million de factures dans le système, devrais-je lire toute l'histoire chaque fois que je veux appliquer une commande? Est-ce que je sauvegarde toujours l'événement sans aucune validation et effectue les validations lors de la construction des modèles/projections de vue?

Si j'ai mal compris une partie du processus, j'apprécierais vos commentaires.

Merci pour votre aide!

Répondre

19

Vous n'êtes pas seul, c'est un malentendu commun. Permettez-moi d'abord répondre à la partie de validation:

Il existe 2 types de validation qui ont lieu dans ce type de système. Le premier est celui où vous recherchez des adresses e-mail valides, des champs numériques uniquement ou obligatoires. Ce type est fait avant même que la commande ne soit émise. Une commande qui contient ce genre de problèmes ne doit pas être considérée comme une commande (pour les courroies et les accolades, vous pouvez vérifier du côté domaine, mais ce n'est pas une question de domaine et il vaut mieux éviter ce scénario).

Le prochain type de validation est quand est un problème de domaine. Ce pourrait être le genre de chose que vous mentionnez où vous vérifiez les prix sont dans un ensemble de paramètres spécifiés. C'est un concept de domaine que les gens d'affaires comprendraient, feraient et pourraient exprimer.

La phase suivante consiste pour le domaine à appliquer le changement d'état et déclencher les événements associés. Ceux-ci sont ensuite persistés et en cas de succès, publiés pour le reste de l'application.

Tout cela peut être fait avec l'agrégat en mémoire. Les actions sont coordonnées avec un service de domaine qui gère la commande. Il charge l'agrégat, applique tous il est événements passés (ou charge un instantané) puis émet la commande. En cas de succès de la commande, il demande tous les nouveaux événements non validés et tente de les persister. En cas de succès, il publie les nouveaux événements. Comme vous le voyez, il charge uniquement les événements pour cet agrégat spécifique. Même avec beaucoup d'événements, ce processus est rapide comme l'éclair. Si la performance est un problème, il existe des stratégies telles que garder les agrégats en mémoire ou les snapshots que vous pouvez appliquer.

Pour votre dernier point concernant la validation des événements. Comme ils ne peuvent être générés que par votre agrégat, ils sont dignes de confiance.

Si vous voulez plus de détails, consultez mon aperçu de CQRS et ES here. Et jetez un oeil à mon post sur la façon de construire des racines agrégées here.

Bonne chance - J'espère qu'ils aident!

+0

Merci, cela aide beaucoup! – amitayh

+0

Génial. Est-ce suffisant d'être marqué comme la réponse? coup de coude.. – Codescribler

0

Il est bon que vous deviez relire l'événement pour «réhydrater» l'agrégat de domaine. Mais vous n'avez pas à rejouer tous les événements pour toutes les factures.Si vous stockez l'identifiant d'entité de l'agrégat racine dans les événements, vous pouvez simplement sélectionner et rejouer les événements ayant l'ID correspondant.

Ensuite, comment trouvez-vous l'identifiant racine agrégé pertinent? Un des référentiels de lecture doit contenir les informations pertinentes pour obtenir l'ID, en fonction d'un ensemble de critères de recherche.