CQRS pueden ser utilizados para un sitio como StackOverflow?

Question

¿Se puede utilizar los CQRS (comandos de consulta Responsabilidad de segregación) patrón arquitectónico para construir un sitio como StackOverflow? Soy relativamente nuevo en CQRS y DDD (Domain Driven Design) y estoy explorando el patrón y tratando de sitios modelo que estoy familiarizado con el patrón. Aunque puedo ver CQRS ser útil para muchos aspectos de un sitio como StackOverflow, hay algunas áreas que no estoy seguro es posible (o, al menos, no puedo averiguar de inmediato). Específicamente:

• Hacer preguntas Cuando creo una pregunta, lo veo inmediatamente y puede editarlo. En CQRS, que emiten un comando como 'AskQuestion' y se crea un evento llamado 'QuestionAsked'. Finalmente, la pregunta es empujado a la almacén de datos sin normalizar. Pero también lo es la experiencia es inmediata. Es esto es posible con CQRS?
• de voto Mis votos se reflejan inmediatamente. En CQRS, Me imagino que estos comandos / eventos con el tiempo se mueve a través del evento autobús a la tienda de lectura. Pero da SO mí la información de forma inmediata.

Mis preocupaciones son realmente alrededor del concepto de retroalimentación inmediata que así lo disponga. Can CQRS proporcionar esto? Si es así, ¿cómo podría hacerse esto? ¿Hay buenos ejemplos por ahí que ilustran cómo manejar esto?

Si ayuda, mi ambiente es VS2010 / C # / SQL2008R2, pero estoy abierto a otras opciones como SQLite, etc. También estoy buscando en los marcos NCQRS y de Lokad, junto con la muestra y la mañana de planificación de Mark Nijhof de descarga muestra de Greg Young. No he encontrado mucho más por ahí para muestras CQRS.

Gracias!

Answer 1

Lo que realmente estamos hablando es de 'consistencia eventual', que se habla con frecuencia sobre al mismo tiempo que CQRS, pero se puede utilizar cualquiera de estas técnicas de forma independiente.

Lo más sencillo que hacer es actualizar el modelo que la interfaz de usuario está utilizando inmediatamente y usar esto para mostrar la parte trasera pregunta al usuario para su posterior manipulación. Las diversas partes de trabajo por hacer para que los otros usuarios puedan ver la actualización puede proceder sin el bloqueo de la interfaz de usuario. Para que esto funcione es necesario validar el comando de modo que es casi seguro de tener éxito antes de enviarlo fuera (si el comando falla durante la ejecución entonces usted necesita para manejar la situación, por ejemplo, incorporar algún tipo de llamada de vuelta al modelo de interfaz de usuario) .

También vale la pena teniendo en cuenta que por lo general el 'eventuallness' de este tipo de cosas es tan rápido que todo habrá aparecido inmediatamente de todos modos, incluso a otros usuarios.

Answer 2

Echemos un vistazo a las dos preguntas ...

El hacer preguntas Cuando creo una pregunta, lo veo de inmediato y se puede editar. En CQRS, expido un comando como 'askQuestion' y se crea un evento llamado 'QuestionAsked'. Con el tiempo, la cuestión es empujado al almacén de datos sin normalizar. Pero la experiencia de SO es inmediata. ¿Es esto posible con CQRS?

Esto se puede lograr fácilmente. ¿Cada usuario necesita para ver la cuestión de inmediato o simplemente la persona que hace eso? Si se tarda 1-2 segundos para que se vean todos los tendría que hacer una diferencia? Lo más a menudo en los sistemas consistentes con el tiempo, hay una diferencia entre el usuario que envía una petición contra cualquier otro usuario.

La votación Mis votos se refleja inmediatamente. En CQRS, me imagino que estos comandos / eventos con el tiempo que se mueven a través del bus de eventos a la tienda de lectura. Pero por lo que me da la información de forma inmediata.

lo hace dar inmediatamente? Vamos a probar otro ejemplo, Facebook. Al hacer clic en algo como muestra esto de inmediato en sus gustos? trucos de interfaz de usuario como poner un pulgar hacia arriba que se sienta como lo hace. Otro ejemplo, el Amazonas. Al hacer clic en añadir a la cesta va a parar de inmediato en su carro? representaciones visuales como "añadido a la cesta" o un "pulgar hacia arriba" que hacer como una sensación de usuario como su hecho.

Hay muchos trucos como estos que pueden hacer que una sensación sistema de consistencia eventual como un sistema totalmente coherente.

Como nota al margen mucha gente piensa este tipo de cosas se hacen para la escalabilidad (que suele ser el caso). Más a menudo que se están haciendo para la fiabilidad. La pregunta es si sucede XYZ es hacia abajo. ¿Quieres fallos locales aleatorios extraños o quiere correr el riesgo de una interrupción de amplia difusión. Uno de los mejores ejemplos que ver aquí es retirar en Amazon por una compra Kindle, su raro que puedan procesar su tarjeta de crédito como 100 ms, mientras que todos los demás tarda 3-5 segundos :) ¿Qué pasa si su sistema de procesamiento de tarjetas de crédito se ha reducido ?

Answer 3

Cuando usted hace una pregunta, puede "falsos" los datos de la interfaz de usuario. Se verá como se actualiza inmediatamente al usuario (usted), pero tomará algún tiempo antes de que los demás usuarios verán tu pregunta. Que tiene que hacer lo mismo con la votación mango.

Si necesita información inmediata, es posible considerar otras soluciones. Sin embargo, hay algunos trucos que puede hacer para dar retroalimentación inmediata en una solución CQRS. Si, por ejemplo, necesidad de validar que un nombre de usuario es uniqe, se puede consultar la base de datos de lectura (s) para averiguar si existe el nombre de usuario. Si no lo hace, se puede usar. Sin embargo, si un usuario ha elegido otra del mismo nombre de usuario en el ínterin, obtendrá un conflicto en el lado de comandos. Es necesario para manejar esto en su modelo de dominio, y, por ejemplo, dar al usuario un nombre de usuario generado y enviársela por correo electrónico. Más tarde se puede cambiar a otra cosa.

Answer 4

Por falsificación o truco, es posible pensar en el evento como un "evento pendiente", algo que es probable que tenga éxito en la fase de confirmación / publicar, pero puede fallar. Cuanto más la validación se realiza del lado del cliente, antes de la primera someter a cometer, es más probable que tenga éxito. Así que si usted tiene la intención de contar con un plan de cometer, a la espera de un cliente más grueso en términos de validación y reglas de negocio exposición.

Uno podría entonces permitir al usuario continuar para utilizar los datos (para la modificación adicional) mediante el marcado o etiquetado de los datos dentro de la interfaz de usuario como depender de "pendiente cometer". Sería un atributo meta del objeto o atributo. Por supuesto agregando y el uso de ese atributo meta aumentará la complejidad, pero dependiendo de la aplicación podría ser un caso de uso es necesario.

las colas de comandos del lado del cliente / historias podrían ser una forma de Gestionar las situaciones de ayuda donde los acontecimientos posteriores se basó en un final no pudo comprometerse en espera. En otras palabras, cualquier cosa que se basa en una pendiente de cometer podría ser parte de una historia que podría ser enrollado, salvado, mientras que las correcciones se hacen a la fallida pendientes cometió, desenrollado y vuelven a aplicar al evento cambiado y vuelto a presentar a la espera de nuevo, y una vez que la notificación de que el evento pendiente fue un éxito en cometer, toda la historia posterior del lado del cliente comenzaría a descansar, presentado el siguiente elemento de la cola, marcándolo como el caso actualmente pendiente.