Je pense que vous devez séparer deux types de validation dans ce cas; validation de domaine et validation d'application .
La validation d'application est ce que vous avez lorsque vous vérifiez que la propriété de commande «texte» est comprise entre 20 et 200 caractères; vous validez donc cela avec l'interface graphique et avec un validateur de modèle de vue qui s'exécute également sur le serveur après un POST. Il en va de même pour le courrier électronique (btw, j'espère que vous vous rendez compte qu'un courrier électronique tel que `32.d +" Hello World .42 "@ mindomän.local" est valide selon la RFC).
Ensuite, vous avez une autre validation; vérifiez que cet article existe - vous devez vous poser la question de savoir pourquoi l'article ne devrait pas exister s'il existe en effet une commande envoyée depuis l'interface graphique qui consiste à y attacher un commentaire. Votre interface graphique a-t-elle finalement été cohérente et vous disposez d'une racine agrégée, l'article, qui peut être physiquement supprimée du magasin de données? Dans ce cas, vous déplacez simplement la commande dans la file d'attente des erreurs car le gestionnaire de commandes ne parvient pas à charger la racine agrégée.
Dans le cas ci-dessus, vous auriez une infrastructure qui gère les messages incohérents - ils réessayeraient par exemple le message 1 à 5 fois, puis le déplaceraient dans une file d'attente empoisonnée où vous pourriez inspecter manuellement la collection de messages et renvoyer ceux qui sont pertinents. C'est une bonne chose à surveiller.
Alors maintenant, nous avons discuté:
Qu'en est-il des commandes qui ne sont pas synchronisées avec le domaine? Peut-être avez-vous une règle dans la logique de votre domaine qui dit qu'après 5 commentaires sur un article, seuls les commentaires en dessous de 400 caractères sont autorisés, mais un gars était trop en retard avec le 5ème commentaire et devait être le 6ème - GUI ne l'a pas saisi car il n'était pas cohérent avec le domaine au moment où il envoyait sa commande - dans ce cas, vous avez un «échec de validation» dans le cadre de votre logique de domaine et vous renverriez l'événement d'échec correspondant.
L'événement peut prendre la forme d'un message sur un courtier de messages ou sur votre répartiteur personnalisé. Le serveur Web, si l'application est monolithique, pourrait écouter de manière synchrone à la fois un événement de réussite et l'événement d'échec mentionné et afficher la vue / partielle appropriée.
Souvent, vous avez un événement personnalisé qui signifie l'échec de nombreux types de commandes, et c'est cet événement auquel vous vous abonnez du point de vue du serveur Web.
Dans le système sur lequel nous travaillons, nous faisons des requêtes-réponses avec des commandes / événements sur un bus de messages MassTransit + RabbitMQ + un courtier et nous avons un événement dans ce domaine particulier (modélisation d'un flux de travail en partie) qui est nommé InvalidStateTransitionError. La plupart des commandes qui tentent de se déplacer le long d'une arête dans le graphique d'état peuvent provoquer cet événement. Dans notre cas, nous modélisons l'interface graphique d'après un paradigme finalement cohérent, et nous envoyons donc l'utilisateur vers une page de `` commande acceptée '' et ensuite laissons les vues du serveur Web se mettre à jour passivement via les abonnements aux événements. Il convient de mentionner que nous faisons également du sourcing d'événements dans les racines agrégées (et le ferons également pour les sagas).
Donc, vous voyez, une grande partie de la validation dont vous parlez sont en fait des validations de type application, et non une logique de domaine réelle. Il n'y a aucun problème à avoir un modèle de domaine simple si votre domaine est simple mais que vous faites DDD. Cependant, au fur et à mesure que vous modélisez votre domaine, vous découvrirez que le domaine n'est peut-être pas aussi simple qu'il l'a été au départ. Dans de nombreux cas, la racine / entité agrégée peut simplement accepter un appel de méthode provoqué par une commande et changer une partie de son état sans même effectuer de validation - en particulier si vous faites confiance à vos commandes comme vous le feriez si vous les validiez sur le serveur Web qui vous contrôlez.
Je peux recommander de regarder les deux présentations sur DDD de la Norwegian Developer Conference 2011 ainsi que la présentation de Greg à Öredev 2010 .
À la vôtre, Henke