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
¿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 por no ir a WCF. Primera ley de diseño de objetos distribuidos de Fowler: No distribuya sus objetos (de PoEAA) – Deleted
+1 - de acuerdo con @Chris Smith –