Plusieurs commandes pour un seul processus dans CQRS

Question

J'ai conçu l'application CQRS + ES. Cela je suis nouveau le monde de CQRS + ES a lu dessus pendant l'année dernière et il fait parfaitement sens mais mettre en application le sens parfait n'est pas toujours facile.

de toute façon ma question ou les questions sont:

quelle est la meilleure façon de contenir un processus de commande multiple (étape)? à-dire l'enregistrement d'un utilisateur ce sont les commandes que je veux tirer dans ce processus:

1. CreateUserProfileCommand
2. CreatePaymentAccountCommand
3. SendEmailAddressVerificationCommand

J'ai regardé La saga ils regardent plus démarrer et arrêter alors ce processus qui est tout continu.

Bien sûr, enchaîner les étapes des événements peut conduire à un cauchemar de relecture.

MISE À JOUR @EbenRoux
Pour ajouter plus d'informations le CreatePaymentAccount devrait effectivement être nommé UpdateUserWithPpaymentAccount. Je vois la confusion dans le nom. Qu'est-ce que cette commande obtient réellement une 3ème partie et obtenir un PaymentCustomerId qui se joint à l'utilisateur.

Je comprends ce que vous dites à propos de Saga et je me demandais si ce processus avait besoin de ça.

À l'heure actuelle, cette application est en cours, donc tout le contexte métier (je suppose que c'est ce que vous entendez par BC) ne possède pas ses points de terminaison pub/sous-point de vue. Je voudrais y aller cependant. Gardez à l'esprit que les commandes ne sont pas relues.

Answer 1

À ce stade de ma compréhension, je considère que les messages système/domaine sont différents de l'événement utilisé dans l'approvisionnement d'événements (ES). Les événements ES sont là pour représenter l'état. Ils ne devraient pas être impliqués dans un traitement. Ils n'aboutiraient jamais à l'exécution d'une commande ou à l'exécution d'une commande. Ils sont simplement un autre moyen de conserver l'état de votre modèle de domaine.

Votre gestionnaire de processus (ce qui est parfois appelé saga) serait un citoyen de première classe dans un autre processus Délimité Contexte (BC) qui coordonne la messagerie du système et son état peut certainement aussi être stockées à l'aide ES.

Vous pouvez router les mêmes messages (si vous le souhaitez) vers différents points d'extrémité provenant de sources différentes. Par exemple: à partir de votre couche frontale/intégration vous pouvez envoyer le CreatUserProfileCommand et le routage l'envoie à votre processus BC où le gestionnaire crée un nouveau UserRegistrationProcess, stocke le flux et envoie le CreateUserProfileCommand qui est maintenant routé vers le User BC.

De la Colombie-Britannique User un UserProfileCreatedEvent est publié que votre processus BC souscrit à et UserRegistrationProcess est mis à jour, le flux est enregistré et un CreatePaymentAccountCommand est envoyé à la Payment BC. Voici un exemple d'un message système (événement) qui aura probablement une structure quelque peu différente de tout ce qui est produit pour le côté ES des choses.

maintenant de la Colombie-Britannique Payment le PaymentAccountCreatedEvent est publié qui est également souscrite par la Colombie-Britannique de processus et le SendEMailAddressVerificationCommand est envoyé à la Colombie-Britannique pertinente.

Tout un modèle commun émerge.

Vous pouvez donc éviter tout cauchemar de relecture puisque les préoccupations sont clairement séparées.

Answer 2

Est-ce juste un cas d'utilisation? I.e Création d'un profil utilisateur?

Je me demande pourquoi ne pas avoir une seule commande, CreateUserProfile qui est ensuite traitée par un gestionnaire de commandes qui orchestre le cas d'utilisation. Tout le reste deviendrait des événements I.e. PaymentAccountCreated, EmailNotificationSent etc ...

Vous pouvez utiliser cette commande pour démarrer un gestionnaire de processus si nécessaire, mais cela dépend de ce que vous devez gérer et de la manière dont les appels externes sont renvoyés. I.e est-ce une simple demande/réponse ou est-ce que le système externe appelle votre API etc

Answer 3

Les événements ne sont pas un cauchemar, ils sont juste la façon dont les choses fonctionnent dans la vraie vie. Si vous envoyez une lettre, vous n'attendez pas la réponse, vous continuez votre vie et quand il y a une réponse, vous prenez la lettre et la lisez.

Vous pourriez en effet utiliser Saga.

1. Initié la saga avec le CreateUserProfileCommand
2. Publier un nouvel événement UserProfileCreatedStarted et avoir le service Paiements écouter cet événement
3. Faire la saga d'inscription vous abonner à la "PaymentAccountCreatedEvent"
4. Publier UserProfileCommandCreated lorsque le processus d'enregistrement est terminé
5. Publier « UserProfileCommandCreated » et terminer la saga et
6. Demandez à votre service de communications abonnez-vous à la UserProfileCommandCreated et envoyer l'e-mail

Jetez un oeil à cet exemple: Saga implementation patterns – variations

L'une des choses que vous voulez éviter est le couplage entre les services, et c'est exactement ce qui arrive quand vous utilisez beaucoup de commandes dans le domaine. Habituellement, les commandes sont générées par l'utilisateur ou à l'intérieur par un « déclencheur » dans le système, à savoir: ChargeMontlyInstallment

En ce qui concerne l'approvisionnement de l'événement et puisque tout cela est nouveau pour vous, jetez un oeil ici: best event sourcing db strategy