Plusieurs commandes par requête HTTP dans la mise en œuvre CQRS

Question

Cette question pourrait être trop demander des détails d'intégration, mais j'espère que c'est aller droit au but.

Dans mon application simple CQRS, j'ai une demande HTTP PUT ressemble ci-dessous qui est censé mettre à jour les détails d'un produit:

PUT http://localhost/products/088c1cb1-7e74-40b1-9900-4b9722f1dd85/details HTTP/1.1 
Content-Type: application/json 
Host: localhost 

{ 
    description: "foo bar", 
    warningDescription: "foo bar", 
    dangerDescription: "foo bar", 
} 

Quand je reçois cette demande, je veux générer trois commandes au lieu de mettre à jour ce droit de suite:

• UpdateProductDescription
• UpdateProductWarningDescription
• UpdateProductDangerDescription

Est-ce réellement le comportement approprié que vous attendez en termes de CQRS ou préférez-vous avoir la commande UpdateProductDetails?

Answer 1

Je pense que cela dépend de la façon dont vous positionnez "Product" et sa "Description" dans votre domaine ou contexte. Si la mise à jour des descriptions a un impact sur votre contexte, j'aurais la commande UpdateProductDescription et je traiterais cette commande. Mais si la mise à jour de la description est similaire à la mise à jour des autres propriétés d'un produit, la commande UpdateProductDetail est correcte.

Answer 2

Faut-il lancer plusieurs commandes par requête http? Probablement vous ne devriez pas. Que se passe-t-il si certaines commandes réussissent mais d'autres non? Traitez-vous plusieurs commandes dans une unité de travail? Même si vous le faites, est-ce juste l'usage de commander? J'en doute. Êtes-vous prêt à mettre en œuvre une logique de retour en arrière dans vos gestionnaires http?

Attention, dans CQRS, une commande peut entraîner plusieurs événements dans la racine de l'aggreagate cible "all or none" car les événements ne peuvent pas échouer. Mais les commandes peuvent.

Alors « une commande générique qui se traduit par plusieurs événements spécifiques » est un meilleur choix que d'essayer de « combiner plusieurs commandes spécifiques dans un appel ». Votre racine agrégée doit décider comment cette commande générique sera exprimée dans des événements spécifiques.

Ainsi, votre logique serait comme ceci:

UpdateGenericProductDescription -> (CommandHandler) -> AggregateRoot -> [ProductDescriptionUpdated, ProductWarningDescriptionUpdated, ProductDangerDescriptionUpdated] 

Voir, même votre entreprise exige que beaucoup granularité, votre commande peut Stil rester générique sauf si requis autrement.