Je crée une application Web CRUD qui, après traitement de la logique interne, publie des événements sur d'autres systèmes afin de mettre à jour leurs données. Je suis dans la première étape de la mise en œuvre de CQRS et il semble bizarre que je doive créer des commandes spécifiques pour toutes les intentions possibles de l'utilisateur dans un formulaire où je n'ai qu'un seul bouton 'sauvegarder'. Cela signifie beaucoup de commandes (pour chaque propriété ou objet de valeur) pour capturer une intention non nécessaire dans mes exigences mais nécessaire dans les projets à venir qui s'y abonneront. Je suis un fan de faire SEULEMENT ce que mon contexte délimité exige.Evénement de commande d'intention CQRS
Autre chose à prendre en compte: Je dois utiliser la session pour comparer si les données ont changé ou non. Le fait de fausser les données après l'avoir sauvegardé masquera les situations de concurrence présentant des données erronées dans l'interface utilisateur.
EDIT: Je viens de découvrirthis thread où Greg Young suggère que certains écrans ne sont que CRUD et il n'y a rien de mal à faire la mise à jour comme comportement par défaut.
Je le fais de cette façon. Mon projet CRUD est un 'outil de configuration' interne permettant de montrer les données correctes sur un site web très fréquenté, j'ai donc besoin de publier des évènements. Ma solution parfaite serait de réaliser ce projet avec juste DDD, sans CQRS, et publier un événement pour chaque intention réelle dans mon champ d'application. Le site Web devrait être réalisé en utilisant CQRS puisqu'il aura des milliers d'utilisateurs. Je ne vois pas pourquoi je dois créer autant de commandes quand mes exigences disent simplement 'créer un formulaire avec un bouton de sauvegarde' – Cesar
Si la seule raison de CQRS est l'évolutivité, alors vous pouvez simplement essayer quelque chose de plus simple. Exemple: utiliser une sorte de cache mémoire pour réduire la charge sur les sites Web (ou publier des vues Web d'une manière qui ne sollicite pas la base de données, par exemple JSON sur CDN) ou simplement modifier la mise en cache par défaut du serveur. CQRS intervient généralement lorsque le projet doit en traiter quelques-unes: gérer des scénarios de gestion complexes, mettre à l'échelle, disposer de capacités BI complètes, s'adapter à des exigences en évolution rapide. –
le scénario est complexe et les systèmes s'exécutent déjà avec memcache. Nous pouvons tirer beaucoup d'avantages des pratiques CQRS, il n'y a aucun doute sur cette décision, le site Web sera reconstruit avec CQRS. Le doute se réfère principalement à ces petits projets entourant le site Web et s'ils devraient envoyer une grosse commande ou de petites commandes à la place (la même chose au sujet des événements). Toutes ces réflexions viennent d'un développeur avec un solide background de DDD, des contextes délimités et une livraison réussie. Maintenant, je dois coder toutes les intentions et gérer la session pour conserver la version des données. (BTW j'aime lire votre blog) – Cesar