CommandHandler et EventHandler order

Question

Je suis nouveau à propos de CQRS et je veux apprendre l'ordre de travail du modèle. Mon gestionnaire de commande et ma commande sont comme suit:

public interface ICommandHandler<in TCommand> where TCommand : ICommand 
{ 
    void Handle(TCommand command); 
} 

Lorsque je charge un travail, un gestionnaire de commandes fonctionne.

public class CreateWorkCommandhandler : ICommandHandler<CreateWork> 
{ 
    public void Handle(CreateWork command) 
    { 
     Save to database...    
    } 
} 

Et je n'appelle pas les gestionnaires de commandes dans les classes de contrôleur. J'utilise un CommandExecuter pour appeler les commandes par type. Je veux envoyer un courriel et envoyer des sms et d'autres choses après le travail créé. Mais je ne peux pas faire ces étapes dans Handle(CreateWork command) en raison de l'architecture séparée. Je pense que ces étapes sont des événements, est-ce vrai? J'ai donc besoin event et event handler types.

public interface IEventHandler<in TEvent> where TEvent : IEvent 
{ 
    void Handle(TEvent event); 
} 

Où puis-je renseigner les événements? Dans CommandExecuter ou CommandHandler J'ai besoin de plusieurs événements pour un événement. par exemple:

public class WorkCreated: IEvent {}

Envoyer un SMS, envoyez un courriel.

Answer 1

 foreach (var handler in handlers) 
     ((dynamic)handler).Handle((dynamic)command); 

Ce semble vraiment bizarre. Pourquoi, dans un contexte ddd/cqrs, y aurait-il jamais plus d'un gestionnaire pour une commande?

Pour un message d'événement, ce modèle pourrait avoir un sens; il est normal qu'un événement ait zéro ou plusieurs abonnés. Mais les commandes sont des messages adressés à une cible spécifique, donc l'énumération d'un certain nombre de gestionnaires semble étrange.

Sur votre question

Je veux envoyer des courriels et envoyer des sms et autre choses après le travail créé. Mais je ne peux pas faire ces étapes dans Handle (commande CreateWork) en raison de l'architecture séparée. Je pense que ces étapes sont des événements, est-ce vrai?

Les événements sont des messages qui décrivent quelque chose qui s'est produit dans le passé. Cela ressemble-t-il à un match? Il me semble que vous décrivez une commande - vous voulez qu'un système envoie un email pour vous. Cela ne ressemble pas à quelque chose qui est déjà arrivé?

EmailCommandSucceeded, SMSCommandFailed, et ainsi de suite plus en détail - ces sont des événements; quelque chose qui est arrivé dans le passé.

Dans ddd, une commande est une proposition de modification de l'état du domaine (à condition que la modification soit autorisée par l'invariant métier appliqué par le modèle de domaine). La réponse du modèle est généralement en deux parties; les données à conserver lors de la validation de la transaction (Repository.save()), et les messages à partager avec le reste du monde. Ces messages peuvent être des événements de domaine ou des commandes à exécuter dans d'autres transactions/contextes.Donc, la réponse habituelle à votre question serait que le gestionnaire de commandes passerait la commande au modèle de domaine, et récupèrerait une liste de commandes à planifier (en dehors du contexte de la transaction). Si le gestionnaire de commandes ne peut pas le faire directement, une alternative pourrait être de publier un EmailCommandScheduledEvent, puis de faire faire le même travail au gestionnaire d'événements.