2011-08-11 18 views
6

Como resultado de un post anterior (Architecture: simple CQS) He estado pensando en cómo podría construir un sistema simple que es lo suficientemente flexible como para extenderse más tarde.cuestión arquitectónica

En otras palabras: no veo la necesidad de un CQRS completo ahora, pero quiero que sea fácil evolucionar a él más adelante, si es necesario.

así que estaba pensando para separar al mando de la consulta, pero ambos basados ​​en la misma base de datos.

La parte de consulta sería fácil: un servicio de datos WCF basado en vistas para que sea fácil consultar datos. Nada especial allí.

La parte del comando es algo más difícil, y he aquí una idea: los comandos se ejecutan, por supuesto, de forma asíncrona, por lo que no devuelven un resultado. Pero, los controladores de mi sitio ASP.NET MVC a menudo necesitan comentarios de un comando (por ejemplo, si el registro de un miembro fue exitoso o no). Entonces, si el controlador envía un comando, también genera una ID de transacción (un guid) que se pasa junto con las propiedades del comando. El servicio de comando recibe este comando, lo coloca en una tabla de transacciones en la base de datos con 'procesamiento' de estado y se ejecuta (utilizando los principios DDD). Después de la ejecución, la tabla de transacciones se actualiza, de modo que el estado se 'completa' o 'falla', y otra información más detallada como la clave principal que se generó.

Mientras tanto, el sitio está utilizando QueryService para sondear el estado de esta transacción, hasta que reciba 'completado' o 'fallido', y luego puede continuar su trabajo en función de este resultado. Si la tabla de transacciones se sondea y el resultado se 'completó' o 'falló', la entrada se elimina.

Un efecto secundario es que no necesito las claves de GUID para mis entidades, lo cual es bueno para el rendimiento y el tamaño.

En la mayoría de los casos probablemente no es necesario este mecanismo de sondeo, pero es posible, si es necesario. Y las interfaces están diseñadas con CQS en mente, de modo que están abiertas para el futuro.

piensa usted de cualquier defecto en este enfoque? Otras ideas o sugerencias?

Gracias!

Lud

+1

¿Por qué desacoplar su interfaz a través de un servicio de datos WCF? ¿Hay alguna razón específica para esto ya que mantendría mi solución lo más simple posible para empezar? – thekip

+1

+1 por no ir a WCF. Primera ley de diseño de objetos distribuidos de Fowler: No distribuya sus objetos (de PoEAA) – Deleted

+0

+1 - de acuerdo con @Chris Smith –

Respuesta

5

Creo que está muy cerca de un sistema CQRS completa con su enfoque.

Tengo un sitio que he usado para hacer algo similar a lo que usted está describiendo. Mi sitio, braincredits.com, está diseñado con CQRS, y todos los comandos son de naturaleza asíncrona. Entonces, como resultado, cuando creo una entrada, realmente no hay retroalimentación para el usuario, excepto que el comando fue exitosamente enviado para el procesamiento (no es que se haya procesado).

Pero tengo una puntuación de usuario en el sitio (un recuento de sus "créditos") que debería cambiar a medida que el usuario envía más elementos. Pero no quiero que el usuario siga presionando F5 para actualizar el navegador. Así que estoy haciendo lo que propones: tengo una llamada AJAX que se dispara cada uno o dos segundos para ver si el recuento de crédito del usuario ha cambiado. Si es así, se recupera la nueva cantidad y se actualiza la interfaz de usuario (con un poco de animación para captar la atención del usuario, pero no demasiado llamativa).

De lo que estás hablando es de una coherencia final: que el estado de la aplicación que el usuario está viendo con el tiempo será coherente con los datos del sistema (el sistema de registro). Ese concepto es bastante clave para CQRS, y, en mi opinión, tiene mucho sentido.Tan pronto como recupera los datos en un sistema (ya sea uno basado en CQRS o no), los datos son antiguos. Pero si asumes eso y asumes que el cliente finalmente será consistente, entonces tu enfoque tiene sentido y también puedes diseñar tu UI para dar cuenta de eso Y aprovechar eso.

En cuanto a sugerencias, vería cuánto sondeos y cuántos datos envía y devuelve. Vete al agua con las encuestas, que parece que no lo eres. Pero apunte a lo que debe actualizarse periódicamente en su sitio y creo que estará bien.

La capa del servicio de datos WCF para el lado de la consulta es una buena idea; solo asegúrese de que solo esté habilitada para lectura (lo cual estoy seguro de que ha hecho).

Aparte de eso, parece que has tenido un buen comienzo.

Espero que esto ayude. ¡Buena suerte!