2010-11-19 32 views
5

Estoy creando una aplicación web CRUD que, después de procesar la lógica interna, publicará eventos en otros sistemas para actualizar sus datos.CQRS intent command event

Estoy en el primer paso de implementar CQRS y suena raro que tengo que crear comandos específicos para todas las intenciones posibles del usuario en un Formulario donde solo tengo un botón 'guardar'. Eso significa una gran cantidad de comandos (para cada propiedad u objeto de valor) para capturar una intención no necesaria en mis requisitos, pero necesaria en los próximos proyectos que se suscribirán. Soy un fan de hacer SOLAMENTE lo que requiere mi contexto delimitado.

Otra cosa a tener en cuenta: Tengo que usar la sesión para comparar si los datos han cambiado o no. Fingir los datos después de guardarlos ocultará las situaciones de concurrencia que muestran datos incorrectos en la IU.

EDIT: Acabo de encontrar this thread donde Greg Young sugiere que algunas pantallas son solo CRUD y no hay nada de malo en hacer que la actualización sea un comportamiento predeterminado.

Respuesta

6

¿Por qué quieres usar CQRS? No funciona bien para todos los casos.

Específicamente, si está utilizando CRUD, entonces no hay ninguna razón para probar CQRS en absoluto. Simplemente no encajará bien. CQRS se beneficia mucho del diseño, cuando la intención del usuario se captura explícitamente en el lado de la interfaz de usuario y se transmite al servidor en un comando significativo (no es FieldNameUpdated, sino más bien CustomerRelocatedToNewAddress o CustomerAddressCorrected). Esto requiere el uso de metodologías de Diseño Dirigido por Dominio en el diseño).

+1

Lo estoy haciendo de esa manera. Mi proyecto CRUD es una "herramienta de configuración" interna para mostrar los datos correctos en un sitio web de alto tráfico, por lo que debo publicar eventos. Mi solución perfecta sería lograr este proyecto solo con DDD, sin CQRS, y publicar un evento para cada intención real en mi alcance. El sitio web debe lograrse utilizando CQRS, ya que tendrá miles de usuarios. No veo por qué tengo que crear tantos comandos cuando mis requisitos solo dicen 'crear un formulario con un botón de guardar' – Cesar

+1

Si la única razón para CQRS es la escalabilidad, entonces puede intentar algo más simple. Es decir: utilizar algún tipo de caché de memoria para reducir la carga en los sitios web (o publicar vistas web de una manera que no acentúe el DB, es decir, JSON en CDN), o simplemente ajustar el almacenamiento en caché predeterminado del servidor. Por lo general, CQRS entra cuando el proyecto necesita lidiar con algunos de estos: maneja escenarios de negocios complejos, escala, tiene capacidades de BI ricas, se adapta a requisitos que cambian rápidamente. –

+0

el escenario es complejo y los sistemas ya se están ejecutando con Memcache. Podemos obtener muchos beneficios de las prácticas de CQRS, no hay dudas acerca de esta decisión, el sitio web será reconstruido con CQRS. La duda se refiere principalmente a los pequeños proyectos que rodean el sitio web y si deben enviar un gran comando o pequeños comandos en su lugar (lo mismo sobre los eventos). Todos estos pensamientos provienen de un desarrollador con sólidos antecedentes de DDD, contextos delimitados y entrega exitosa. Ahora tengo que codificar todos los intentos y tratar con la sesión para mantener la versión de los datos. (Por cierto, me encanta leer su blog) – Cesar