Cómo manejar los errores posteriores a la validación en el comando (DDD + CQRS)

  

Entiendo que los comandos no deben devolver nada.

Esa es una vista, pero no está completamente escrita en piedra. Considere las escrituras (PUT, POST, DELETE) en HTTP: todos estos mensajes son comandos, en el sentido de que son mensajes que solicitan que el recurso cambie de estado y, sin embargo, todos devuelven respuestas.

  

Entonces, ¿cómo maneja un error más allá de Command Bus? (Por ejemplo, un usuario se registró 1 segundo antes con el mismo nombre de usuario / correo electrónico).

     

¿Cómo sabes que falló el comando y cómo sabes el error?

Por lo tanto, en el caso de que se esté comunicando directamente con el controlador de comandos, un mensaje devuelto es una forma perfectamente razonable de reconocer que el comando se ha recibido y procesado.

Si está utilizando una pieza de middleware, como un bus, que le impide comunicarse directamente con el objetivo, le sugiero que busque patrones de mensajería asíncronos: ¿cómo puede hacer que el controlador de comandos envíe un mensaje? de vuelta a la persona que llama?

Una idea es suscribirse al resultado del comando; esto se basa en algunas de las ideas de los patrones de integración empresarial de Hohpe. La idea básica es que, dado que el cliente está familiarizado con el mensaje de comando que se envió, está bien posicionado para suscribirse a cualquier mensaje nuevo publicado como consecuencia del mensaje de comando. El controlador de comandos, después de guardar los datos en el libro de registro, publica eventos que anuncian que el cambio fue exitoso, y el cliente se suscribe a esos eventos, reconociendo los eventos correctos al considerar la coincidencia de varios identificadores en el mensaje (identificación de causación, ID de correlación , y así sucesivamente).

Los enfoques alternativos son un poco más directos. Una de ellas sería incluir en el mensaje una devolución de llamada, que puede ser invocada por el controlador de comandos después de que el mensaje se maneje con éxito.

Una alternativa muy similar es reservar espacio en el mensaje de comando para que el controlador de comandos escriba el acuse de recibo, ya que el cliente ya tiene el mensaje de comando en cuestión, el circuito ya está completo. Piense " promesa " o " futuro completable". El mensaje le indica al controlador de comandos dónde escribir el acuse de recibo; al hacerlo, se le indica al cliente (cuenta atrás) que el reconocimiento está disponible.

Y, por supuesto, tiene la opción adicional de eliminar el middleware que parece estar obstaculizando la tarea de hacer lo correcto simplemente.

  

Por ejemplo, un usuario se registró 1 segundo antes con el mismo nombre de usuario / correo electrónico

Si está manejando el registro de usuarios de forma involuntaria, eso no sería necesariamente un error: repetir los mensajes hasta que se observe una respuesta es una forma común de garantizar al menos una vez la entrega.

  

Por ejemplo, cuando envía un formulario de Registro, debe verificar en el Modelo de dominio (WriteModel en CQRS) que está en un estado válido (por ejemplo, sintaxis de la dirección de correo electrónico, edad, etc.)

Hay muchos tipos de validación. La validación cuando se comprueba la sintaxis de la dirección de correo electrónico y el formato de antigüedad es un tipo de validación que puede realizar un comando. Esto no es realmente una preocupación de dominio. Puede parecer así porque algunos expertos en dominios le dirían esas especificaciones, pero debería hacer este tipo de validación en la creación del comando. De hecho, la idea general es hacer la validación tan pronto como sea posible porque después de crear un comando y enviarlo a un BUS, es más complicado tomar medidas.

  

Entonces, ¿cómo maneja un error más allá de Command Bus? (Por ejemplo, un usuario se registró 1 segundo antes con el mismo nombre de usuario / correo electrónico).

Este tipo de validación se discute mucho en la comunidad CQRS, desde el comienzo de CQRS. Donde lo haces Es muy debatido. Personalmente uso el siguiente enfoque: Antes de enviar el comando al BUS, marque el nombre de usuario / correo electrónico como tomado de manera centralizada (es decir, una restricción de índice única en el nombre de usuario / correo electrónico). Después de eso envío el comando. El inconveniente es que, si el comando falla, durante un corto período de tiempo se toma y se usa ese nombre de usuario; esto es aceptable para mi negocio, probable para su negocio.

  

¿Cómo sabes que falló el comando y cómo sabes el error?

Si un comando asíncrono es rechazado por el agregado debido a un dominio invariante, se deben tomar algunas medidas al emitir un comando compensatorio que de alguna manera notifica al emisor del comando (es decir, enviar una explicación por correo electrónico de que el comando falló). p>

El problema con el correo electrónico duplicado es que no puede enviar un correo electrónico porque esa dirección de correo electrónico pertenece a otra persona, por eso lo verifico antes de enviar el comando al bus.

La validación debe realizarse en un decorador. Entonces cualquier comando que necesite validación podría ser decorado como tal.

Las validaciones se pueden manejar con excepciones si devuelve vacío con su comando para que puedan ser recogidas con las llamadas de sincronización o asíncronas con el resultado de la tarea devuelta.

Otra posibilidad es pensar en la validación como un tipo de "consulta" que devolvería un resultado de validación. Ejecute la consulta de validación y luego, si se pasa, ejecute el comando. Esta sería una alternativa al enfoque del decorador.