Validation et bugfixing dans CQRS

Question

Je reçois le concept général de CQRS, mais j'ai quelques questions en ce qui concerne le dépassement de l'exemple de code et de diapositives qui sont là pour faire face aux problèmes du monde réel.

1. Validation

   Lorsque vous devez faire la validation d'une commande qui implique de vérifier les valeurs de la base de données, que faites-vous? Prenez l'inscription pour un service, je dois saisir une adresse e-mail unique. Un argument que j'ai entendu est qu'il est très peu probable que l'utilisateur saisisse une adresse e-mail en double, alors gérez-la simplement lors du traitement de la commande et envoyez-leur un e-mail disant "désolé", ou peut-être suggérant qu'ils réinitialisent leur mot de passe. Ce processus évite donc d'avoir un redmodel pour le bien de la validation. Mais comment gérez-vous le cas en double dans le gestionnaire de commandes? Comment savez-vous alors que c'est un double? Vérifiez un ReadModel? Vous pourriez aussi bien avoir utilisé cela en premier lieu pour une meilleure convivialité.

2. Modifications de la fonctionnalité / fixation des bogues

   Que se passe-t-il lorsque vous devez modifier le fonctionnement d'une commande ou corriger un bug? Dans la philosophie de consoudeur uniquement, que dois-je faire avec toutes les anciennes commandes et gestionnaires de commandes? Je ne peux pas les renommer à la _LEGACY et les cacher sinon la désérialisation de mon événement ne fonctionnera pas. Quelles solutions élégantes y a-t-il pour faire face à cela?

Merci

Answer 1

1. Voir http://codebetter.com/blogs/gregyoung/archive/2010/08/12/entual-constance-and-set-validation.aspx et la liste de diffusion CQRS pour les différentes discussions sur ce sujet.
2. Le versioning d'événements (il n'y a pas besoin de version de commandement au même sens que le versioning d'événements) est également discuté sur la liste de diffusion CQRS. Les événements sont rejoués pour atteindre l'état actuel d'un agrégat, pas des commandes. De cette façon, votre fonctionnalité peut évoluer. Il n'y a aucun moyen de changer le passé, mais il existe des moyens de changer le présent / l'avenir. Dans le cas étrange, vous devez commencer à suivre l'état d'une manière différente, fournissez une commande explicite. Pour les nouvelles propriétés sur les événements, fournissez simplement des défauts comme vous le feriez pour une nouvelle colonne de base de données. Si ces nouvelles valeurs sont basées sur l'état déjà présent, modélisez une commande explicite pour les précalculer. L'avantage est que vous pouvez le faire de manière asynchrone, tandis qu'une mise à niveau de la base de données vous oblige également à modifier le code. Comment cela fonctionnerait est mieux demandé sur la liste de diffusion CQRS.Un avertissement! Ne prenez pas la source d'événements trop à la légère. Vous pouvez vous débrouiller avec seulement CQRS. Je vois des gens passer à CQRS + ES quand la plupart du temps, les CQR feront.

Alors, venez sur groupes.google.com/group/dddcqrs et obtenez de l'aide. Une autre ressource utile est cqrsinfo.com