2009-12-10 36 views
21

Uno de los principios básicos de CQRS, según tengo entendido, es que los comandos deben estar centrados en el comportamiento y tener un valor en el negocio o UL y no estar centrados en datos, es decir, CRUD . En lugar de centrarnos en actualizar un cliente, tenemos comandos como CustomerHasMoved. ¿Qué sucede si tiene pantallas CRUD que están ahí para corregir ciertos datos? Por ejemplo, necesitamos cambiar el nombre de un cliente que está mal escrito. Esto realmente no tiene mucho valor en el negocio. ¿Debería esto solo estar bajo el paraguas de un comando UpdateCustomer?CQRS y pantallas CRUD

+4

¿De qué manera tener el nombre correcto del cliente no tiene valor para la empresa? Poner el nombre equivocado puede significar que los productos no se entregan y hay otros escenarios ... – Oded

Respuesta

17

En realidad, puede haber varias razones para actualizar el nombre de un cliente. Como estabas diciendo, podría estar mal escrito o ... podrías casarte y cambiar tu nombre por el de tu esposo.

Si solo tuviera un comando UpdateCustomer, perdería el intento original y no podría tener comportamientos diferentes para cada uno de ellos. Si el nombre fue mal informado, podría ser tan simple como actualizar la base de datos, mientras que si su cliente se casara, podría necesitar notificar al departamento de mercadotecnia para que puedan ofrecer un descuento.

En el caso de que su entidad sea puramente CRUD, es decir, no hay ninguna intención de que pueda asociarla con la modificación de las propiedades, entonces está bien tener un UpdateEntityCommand. A continuación, puede realizar la transición lentamente a algo más basado en tareas

+1

Exactamente, ¿qué hay que hacer? Crear un comando para cada escenario posible? – blockhead

+7

Sí, o al menos para cada escenario que desee manejar. En mi ejemplo, comenzarías con CorrectMisspelledCustomerName y luego, si es necesario, agregarás un comando MakeCustomerMarried. CQRS es sobre el comportamiento, no sobre la actualización de datos. Por lo tanto, no debe tener comandos genéricos para actualizar cosas en su sistema – Julien

+0

¿Qué sucede si tengo una pantalla grande con todos los campos para mi cliente? ¿Desearía disparar varios comandos para manejar eso, o de alguna manera encontrar algún tipo de "comportamiento" para eso? Quizás nunca debería mostrar todos los campos. – blockhead

0

CustomerHasMoved es el evento que se activa después de haber actualizado la ubicación del cliente. Este evento actualiza las bases de datos de lectura/caché. El comando de la GUI debe ser MoveCustomer o algo así. Creo que pondría la actualización del nombre del cliente en un comando como UpdateCustomer.

37

Solo quiero poner un comentario sobre esto tan pronto como apareció.

Es importante tener en cuenta que algunos objetos son realmente CRUD y eso está bien. Puede que realmente no me importe por qué un nombre está cambiando en mi dominio, donde envío productos a las personas y solo necesito esa información para imprimir etiquetas postales. El truco está en hacer que el comportamiento sea el predeterminado y ENTONCES revertir a una interfaz CRUD una vez que esté seguro de que realmente no le importan las razones en lugar de viceversa.

Greg

+0

Gracias por su entrada @Greg. Estaba buscando en Google para ver lo que tenía que decir sobre estos tipos de escenarios CRUD. Supongo que ocasionalmente se puede usar CRUD ocasionalmente en un enfoque DDD, siempre y cuando no haya absolutamente ningún comportamiento que quieras capturar junto con él. –

+0

Votación. Estamos gastando dinero aquí para obtener funcionalidad (con capacidad de mantenimiento en segundo lugar). Quiero hacer algo perfecto y hermoso, ser un artista. Que te paguen como uno, también. Vea mi comentario a la respuesta de Julien. – FastAl