suivre le conseil dans affronter la Complexité dans CQRS par Vladik Khononov suggère que la manipulation de commande peut retourner des informations relatives à son résultat.

sans violer aucun principe [CQRS], une commande peut retourner en toute sécurité les données suivantes:

• résultat D'exécution: succès ou échec;
• messages D'erreur ou erreurs de validation, en cas d'échec;
• le numéro de la nouvelle version de l'agrégat, en cas de succès;

cette information améliorera considérablement l'expérience utilisateur de votre système, car:

• Vous n'avez pas à interroger une source externe pour l'exécution d'une commande suite, vous avez tout de suite. Il devient trivial de valider des commandes et de retourner des messages d'erreur.
• si vous voulez rafraîchir les données affichées, vous pouvez utiliser la nouvelle version de l'agrégat pour déterminer si le modèle de vue reflète ou non la commande exécutée. Aucun de plus l'affichage des données périmées.

Daniel Whittaker, qui prône le retour à un "commune" objet à partir d'un gestionnaire de commande contenant cette information.

Eh bien, est-ce que les gestionnaires de commandes renvoient des valeurs ou non?

Ils ne devraient pas retourner Données Sur Les Entreprises, seuls les méta-données (concernant le succès ou l'échec de l'exécution de la commande). CQRS CQS prise à un niveau supérieur. Même si tu enfreins les règles du puriste et que tu rends quelque chose, que retourneras-tu? Dans CQRS le handler de commande est une méthode de application service chargement aggregate appelle alors une méthode sur le aggregate puis il persiste aggregate. L'intention du gestionnaire de commande est de modifier le aggregate. Vous ne savez pas ce retour qui serait indépendant de l'appelant. Chaque appelant/client du gestionnaire de commandes voudrait savoir quelque chose d'autre sur le nouvel état.

si l'exécution de la commande bloque (alias synchrone), alors tout ce que vous devez savoir, c'est si la commande a été exécutée avec succès ou non. Puis, dans une couche supérieure, vous interrogez la chose exacte que vous devez savoir sur la nouvelle application de l'état à l'aide d'une requête-modèle qui est le mieux adapté à vos besoins.

pensez autrement, si vous renvoyez quelque chose d'un gestionnaire de commandes, vous lui donnez deux responsabilités: 1. modifier l'état agrégé et 2. requête de certains lisent-modèle.

en ce qui concerne la validation des commandes, il existe au moins deux types de validation des commandes:

1. contrôle de santé de commande, qui vérifie qu'une commande a les données correctes (c.-à-d. une adresse e-mail est valide); ceci est fait avant que la commande atteigne l'agrégat, dans le gestionnaire de commandes (le service d'application) ou dans le constructeur de commandes;
2. vérification des invariants de domaine, qui est effectuée à l'intérieur de l'agrégat, après que la commande atteigne l'agrégat (après qu'une méthode est appelée sur l'agrégat) et elle vérifie que l'agrégat peut muter vers le nouvel état.

cependant, si nous montons un certain niveau, dans le Presentation layer (c'est à dire un REST endpoint), le client du Application layer, nous vous pouvez retourner n'importe quoi et nous n'enfreindrons pas les règles parce que les endpoints sont conçus après les cas d'utilisation, vous savez exactement ce que vous voulez retourner après l'exécution d'une commande, dans chaque cas d'utilisation.

CQRS et CQS sont comme des microservices et la décomposition de classe: l'idée principale est la même ("tendent à de petits modules cohésifs"), mais ils se trouvent sur des niveaux sémantiques différents.

le but de CQRS est de faire une séparation entre les modèles en écriture et en lecture; de tels détails de bas niveau comme la valeur de retour d'une méthode spécifique ne sont absolument pas pertinents.

prenez note de ce qui suit citation de Fowler:

le changement introduit par le CQRS est de diviser modèle conceptuel en modèles séparés pour la mise à jour et l'affichage, qu'il se réfère comme commande et requête respectivement en suivant le vocabulaire de la séparation de la commande.

C'est sur modèles, pas méthode.

le gestionnaire de commandes peut renvoyer n'importe quoi sauf les modèles de lecture: état (succès/échec), événements générés (c'est le but principal des gestionnaires de commandes, btw: générer des événements pour la commande donnée), erreurs. Manipulateurs de commandes très souvent jeter exception non contrôlée, il est un exemple de signaux de sortie des gestionnaires de commandes.

D'ailleurs, L'auteur du terme, Greg Young, dit que les commandes sont toujours synchronisées (sinon, cela devient événement): https://groups.google.com/forum/#!topic/dddcqrs/xhJHVxDx2pM

Greg Young

en fait, j'ai dit qu'une commande asynchrone n'existe pas :) sa fait un autre événement.

réponse pour @Constantin Galbenu, j'ai affronté limit.

@Misanthrope et que faites-vous exactement avec ces événements?

@Constantin Galbenu, dans la plupart des cas, je n'en ai pas besoin suite à l'ordre, bien sûr. Dans certains cas -- je dois aviser le client en réponse à cette demande D'API.

Il est extrêmement utile lorsque:

1. vous devez signaler une erreur via des événements plutôt que des exceptions. Il se produit généralement lorsque votre le modèle doit être sauvegardé (par exemple, il compte le nombre de tentatives avec le mauvais code/mot de passe) même si une erreur s'est produite. En outre, certains gars n'utilisent pas d'exceptions pour les erreurs d'affaires du tout -- seulement des événements (http://andrzejonsoftware.blogspot.com/2014/06/custom-exceptions-or-domain-events.html) il n'y a pas de raison particulière de penser que lancer des exceptions d'affaires depuis le gestionnaire de commandes est OK, mais retourner des événements de domaine n'est pas.
2. Quand l'événement se produit seulement avec quelques circonstances à l'intérieur de votre racine agrégée.

Et je peux donner des exemple pour le deuxième cas. Imaginez que nous fassions un service semblable à Tinder, nous avons un commandement semblable àtranger. Cette commande peut avoir pour résultat une réponse Etrangère si nous aimons la personne qui nous a déjà aimé avant. Nous avons besoin d'informer le client mobile en réponse si la correspondance a eu lieu ou non. Si vous voulez juste vérifier matchQueryService après la commande, vous pouvez trouver match là, mais il n'y a pas de garantie que match qui s'est passé dès maintenant, parce que parfois Tinder montre déjà appariés étrangers (probablement, dans les zones non peuplées, peut-être incohérence, probablement vous avez juste 2nd dispositif, etc.).

vérifier la réponse si StrangersWereMatched vraiment arrivé en ce moment est si simple:

$events = $this->commandBus->handle(new LikeStranger(...));

if ($events->contains(StrangersWereMatched::class)) {
  return LikeApiResponse::matched();
} else {
  return LikeApiResponse::unknown();
}

Oui, vous pouvez introduire le code de commande, par exemple, et de faire Correspondre les lire de modèle pour le garder:

// ...

$commandId = CommandId::generate();

$events = $this->commandBus->handle(
  $commandId,
  new LikeStranger($strangerWhoLikesId, $strangerId)
);

$match = $this->matchQueryService->find($strangerWhoLikesId, $strangerId);

if ($match->isResultOfCommand($commandId)) {
  return LikeApiResponse::matched();
} else {
  return LikeApiResponse::unknown();
}

... mais pensez-y: pourquoi pensez-vous que le premier exemple avec la logique pure est pire? Il ne viole pas CQRS de toute façon, j'ai juste fait l'implicite. Il est apatride immuable approche. Moins de chances de toucher un bug (par exemple si matchQueryService est mis en cache ou en différé [pas immédiatement compatibles], vous avez un problème).

Oui, lorsque le fait d'apparier n'est pas suffisant et que vous avez besoin d'obtenir des données pour répondre, vous devez utiliser le service d'interrogation. Mais rien ne vous empêche de recevoir des événements à partir du gestionnaire de commande.