Pouvez-vous utiliser le modèle architectural de la CQRS (ségrégation de la responsabilité de la requête de commande) pour construire un site comme Stackoverflow? Je suis relativement nouveau chez CQRS et DDD (conception dirigée sur le domaine) et je suis en train d'explorer le modèle et d'essayer de modéliser des sites que je connais au motif. Bien que je puisse voir les CQRS d'être utiles à de nombreux aspects d'un site comme Stackoverflow, il y a quelques zones que je ne suis pas sûre n'est possible (ou au moins, je ne peux pas comprendre immédiatement). Plus précisément:
Mes préoccupations sont vraiment autour du concept de commentaires immédiats qui fournit donc. Les CQRS peuvent-ils fournir ceci? Si oui, comment cela serait-il fait? Y a-t-il de bons exemples qui illustrent comment gérer cela?
Si cela aide, mon environnement est VS2010 / C # / SQL2008R2, mais je suis ouvert à d'autres options telles que SQLite, etc. Je suis également en train de regarder les cadres de NCQRS et de Lokad, avec l'échantillon de Mark Nijhof et envisage de télécharger Échantillon de Greg Young. Je n'ai pas trouvé beaucoup d'autre là pour les échantillons de CQRS.
Merci!
4 Réponses :
Lorsque vous posez une question, vous pouvez «simuler» les données de l'interface utilisateur. On dirait que cela a été mis à jour immédiatement à l'utilisateur (vous), mais cela prendra du temps avant que les autres utilisateurs ne voient votre question. Vous devez faire la même chose pour gérer le vote.
Si vous avez besoin de commentaires immédiats, vous pourriez envisager d'autres solutions. Mais vous pouvez faire quelques astuces pour donner des commentaires immédiats dans une solution CQRS. Si vous, par exemple, devez valider qu'un nom d'utilisateur est UNIQE, vous pouvez interroger la ou les bases de données de lecture pour savoir si le nom d'utilisateur existe. Si ce n'est pas le cas, vous pouvez l'utiliser. Mais si un autre utilisateur a choisi le même nom d'utilisateur dans l'intervalle, vous obtiendrez un conflit sur le côté de la commande. Vous devez gérer cela dans votre modèle de domaine et, par exemple, donner à l'utilisateur un nom d'utilisateur généré et lui envoyer par e-mail. Il peut plus tard le changer à autre chose.
"Faux" et "Trick" ne sont pas très rassurants ... Cela ressemble plus à un hack, une solution de contournement plutôt qu'une solution sonore.
Par faux, je veux dire que vous n'avez pas besoin d'envoyer des données à la base de données / serveur avant d'aller à un écran où les données sont nécessaires. Il n'y a pas de problème à attendre que les données soient via le système (écrinide et longeide), mais vous devez former l'utilisateur pour actualiser l'écran ou configurer une sorte de mécanisme de traction. Cela peut avoir un impact sur l'expérience utilisateur. Et, ce n'est pas un hack d'être intelligent ;-)
Ce que vous parlez réellement, c'est une «cohérence éventuelle» qui est souvent parlée à la même heure que les CQRS, mais vous pouvez utiliser une technique de manière indépendante.
La chose la plus simple à faire est de mettre à jour le modèle que l'interface utilisateur utilise immédiatement et utilisez-la pour afficher la question à l'utilisateur pour une manipulation supplémentaire. Les différents bits de travail à faire pour que les autres utilisateurs puissent voir la mise à jour puisse ensuite procéder sans bloquer l'interface utilisateur. Pour que cela fonctionne, vous devez valider votre commande de sorte qu'il est presque certain de réussir avant de l'envoyer (si la commande échoue pendant l'exécution, vous devez gérer la situation, par exemple, incorporer une sorte de rappel au modèle d'interface utilisateur) .
Il convient également de garder à l'esprit que l'éventualité de ce type de chose est tellement rapide que tout aurait comparu immédiatement, même à d'autres utilisateurs.
Par faux ou truc, vous pourriez penser à l'événement en tant que "événement en attente", ce qui risque de réussir dans la phase de validation / publication, mais pourrait échouer. Plus vous effectuez la validation des clients, avant la soumission initiale pour commenter, plus elle réussira probablement. Donc, si vous avez l'intention de compter sur une validation en attente, planifiez un client plus épais en termes d'exposition de la validation et de la règle des entreprises.
On pourrait alors permettre à l'utilisateur de continuer à utiliser les données (pour une modification ultérieure) en marquant ou en marquant les données dans l'interface utilisateur en s'appuyant sur "En attente de validation". Ce serait un attribut méta de l'objet ou de l'attribut. Bien entendu, l'addition et l'utilisation de cet attribut Meta augmenteront la complexité, mais en fonction de l'application pourraient être un cas d'utilisation nécessaire.
Les files d'attente / histoires de commandes de la clientèle pourraient être une solution pour aider à gérer les situations dans lesquelles des événements ultérieurs invoqués sur un échec en fin de compte en attente de validation. En d'autres termes, tout ce qui s'appuie sur un commit en attente pourrait faire partie d'une histoire pouvant être déployée, sauvegardée alors que les corrections sont apportées à l'échec en attente de validation, déroulée et réappliquée à l'événement en attente modifié et renvoyé, et une fois notification que L'événement en attente a été réussi en validant, tous les antécédents secondaires de la clientèle commenceraient à se détendre, ont soumis le point suivant dans la file d'attente, ce qui le marquait comme étant actuellement en attente.
Regardons les deux questions ...
poser des questions lorsque je crée une question, je le vois immédiatement et peut le modifier. Dans les CQRS, je publie une commande comme "AskQuestion" et un événement est créé appelé "quesitair". Finalement, la question est poussée au magasin de données dénormalisé. Mais l'expérience de To est immédiate. Est-ce possible avec les CQRS?
Ceci peut être facilement réalisé. Est-ce que chaque utilisateur doit voir la question immédiatement ou simplement la personne la demandant? S'il faut 1 à 2 secondes pour qu'il apparaisse à tout le monde cela ferait une différence? Le plus souvent dans des systèmes éventuellement cohérents, il existe une différence entre l'utilisateur qui envoie une demande vs tous les autres utilisateurs.
Voter mes votes sont reflétés immédiatement. Dans les CQRS, j'imagine que ces commandes / événements finissent par se déplacer dans le bus d'événement vers le magasin de lecture. Mais me donne donc l'information immédiatement.
le fait-il donc immédiatement? Essayons un autre exemple, Facebook. Lorsque vous cliquez sur quelque chose, cela apparaît-il immédiatement dans vos goûts? Des astuces de l'interface de l'interface de l'interface de l'interface de l'interface de l'interface de l'assurance-emploi Un autre exemple, Amazon. Lorsque vous cliquez sur Ajouter au panier, l'est-il immédiatement dans votre panier? Des représentations visuelles telles que "ajoutées au panier" ou un "pouce en haut" vous font que l'utilisateur a l'impression que c'est fait.
Il existe de nombreuses astuces comme celles-ci pouvant faire un système finalement cohérent se sentir comme un système totalement cohérent.
En tant que note latérale, de nombreuses personnes pensent que ces types de choses sont effectuées pour l'évolutivité (ce qui est parfois le cas). Plus souvent, ils sont faits pour la fiabilité. La question devient se produit si XYZ est en panne. Voulez-vous des échecs locaux randomisés étranges ou souhaitez-vous risquer une large manquement. L'un des meilleurs exemples à voir ici est de vérifier sur Amazon pour un achat Kindle, c'est bizarre qu'ils peuvent traiter votre carte de crédit comme 100 ms tandis que tout le monde prend 3-5 secondes :) Que se passe-t-il si leur système de traitement de carte de crédit est en panne ?
Qu'est-ce que les CQRS doivent faire, avec quelque chose qui se fait "immédiatement" ou non? Si vous envoyez l'événement
questionasked , vous pouvez être sûr qu'il est terminé et il est donc mis à jour sur le côté frontal. Si la base de données est mise à jour immédiatement ou en 10 minutes ne fait pas une différence pour l'utilisateur. Bien sûr, si une erreur se produit, vous voudrez peut-être donner des commentaires à l'utilisateur, mais il y a beaucoup de possibilités là-bas. Cela serait également vrai pour un système de messagerie instantanée. Il vous suffit de vous assurer que vos messages sont persistés et redirigés assez rapidement, il s'agit donc d'une question d'infrastructure / de performance.