Question

CQRS m'a obtenu en mode pensant .. Je suis tryinng de commencer un nouveau projet avec des idées de CQRS. Les principales choses que je aime est
1) la séparation des requêtes et commandes. Nos requêtes de domaine ont été un problème.
2) À l'aide de stockage de l'événement pour la vérification - je ne vais pas l'utiliser pour Replay - du moins pas maintenant.

Je suis bien avec le côté de la requête et j'ai encore quelques questions sur des événements de domaine

Si un résultat de commande à updation de plusieurs agrégats Roots (Ex. Ordre et OrderDetail) J'auront la leur portée a été définie sous UnitOfWork (transactionnel). Maintenant, chaque domaine est responsable des événements publication lorsqu'un changement a lieu à son état.

disons la commande change 3 enregistrements OrderDetail. Chaque OrderDetail publiera 2 Events. En fin de compte, nous avons 6 événements.

a) Si je publie les événements dès que je l'ai fait les modifications apportées à l'objet de domaine (mais pas commis la transaction) Comment inverser les événements qui ont été publiés (et peut-être consommé par les abonnés)

  • Ce que je peux penser est de tenir les événements à publier dans une liste « sous la même unité de portée de travail » et une fois que la transaction sur committ a été appelé, le stocker et de le publier. Est-ce un son quelque chose ferait.

b) Si les changements OrderDetail exige que des changements aussi avoir lieu pour Aggregate Racine puis
    i) Dois-je baser ces changements en manipulant les événements publiés par OrderDetail Aggregate? Ex. disons deux détail de la commande ont été retirés. Cela rend le statut ordre, de « préféré » à « Non préféré ».     ii) si les erreurs de l'événement et ne pas mettre à jour l'état de la commande -. Si des restes de commande préféré alors il s'expédié en 2 jours

Ajouter une autre question c) Les « événements de domaine sont la source de tous état de l'application des modifications » ou sont-ils « Résultat de tous les changements d'état de l'application »

Je vous remercie à l'avance,

Le Mar

Était-ce utile?

La solution

a) vous ne devriez pas publier des événements jusqu'à ce que votre transaction est engagée, un reprsent d'événement quelque chose qui est arrivé , et donc la raison pour laquelle ils sont tous nommés en passe temps (par exemple OrderClearedEvent). En outre, dans le cas que vous devez « revert » un événement, vous devez prendre des mesures correctives, soit vous n'effacer l'événement, vous devez déclencher un nouvel événement qui corrige les effets de l'événement que vous souhaitez rétablir les paramètres

b) il semble que ce soit plus d'un problème sur la façon dont vous vous modéliser des entités et des commandes que toute autre chose. Je ne peux pas penser à une raison pour laquelle OrderDetail serait un AggregateRoot, mais je ne sais pas votre domaine ...

c) Commandes se traduira par au moins un événement en cours de publication

Hope this helps :) Comme Rinat dit, le groupe Google est le meilleur endroit pour poser des questions, ont aussi un oeil à cqrsinfo.com et le code de l'échantillon de github.com/MarkNijhof/Fohjin et github.com/gregoryyoung/ mr

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top