CQRS Event Sourcing: Validar la unicidad del nombre de usuario

Creo que todavía tienes que tener el cambio de mentalidad hacia la consistencia final y la naturaleza del abastecimiento de eventos. Yo tenía el mismo problema. Específicamente me negué a aceptar que debas confiar en los comandos del cliente que, usando tu ejemplo, dicen "Haz este pedido con un 10% de descuento" sin que el dominio valide que el descuento deba seguir adelante. Una cosa que realmente me impactó fue algo que el propio Udi me dijo (revisa los comentarios de la respuesta aceptada).

Básicamente me di cuenta de que no hay razón para no confiar en el cliente; todo en el lado de lectura se ha producido desde el modelo de dominio, por lo que no hay razón para no aceptar los comandos. Lo que sea en el lado de lectura que dice que el cliente califica para el descuento ha sido puesto allí por el dominio.

POR cierto: En el requisito, si el nombre de usuario introducido ya está tomado, el sitio web debe mostrar el mensaje de error "Lo sentimos, el nombre de usuario XXX no está disponible" para el visitante. No es aceptable mostrar un mensaje, por ejemplo, "Estamos creando su cuenta, espere, le enviaremos el resultado del registro por correo electrónico más tarde", al visitante.

Si va a adoptar el aprovisionamiento de eventos y la consistencia eventual, tendrá que aceptar que a veces no será posible mostrar mensajes de error al instante después de enviar un comando. Con el ejemplo de nombre de usuario único, las posibilidades de que esto suceda son tan escasas (dado que revisa el lado de lectura antes de enviar el comando) no vale la pena preocuparse demasiado, pero una notificación posterior tendría que ser enviada para este escenario, o tal vez pedirles un nombre de usuario diferente la próxima vez que inicien sesión. Lo bueno de estos escenarios es que te hace pensar en el valor del negocio y lo que es realmente importante.

ACTUALIZACIÓN: Oct 2015

Solo quería agregar, que en realidad, en lo que respecta a los sitios web de cara al público, indicar que un correo electrónico ya está tomado es en realidad contra las mejores prácticas de seguridad. En su lugar, el registro debe parecer haber pasado por informar con éxito al usuario que se ha enviado un correo electrónico de verificación, pero en el caso de que exista el nombre de usuario, el correo electrónico debe informarles de esto y pedirles que inicien sesión o restablezcan su contraseña. Aunque esto solo funciona cuando se usan direcciones de correo electrónico como nombre de usuario, lo que creo que es recomendable por esta razón.

No hay nada malo en crear algunos modelos de lectura inmediatamente consistentes (por ejemplo, no sobre una red distribuida) que se actualizan en la misma transacción que el comando.

El hecho de que los modelos de lectura sean consistentes a través de una red distribuida ayuda a soportar el escalado del modelo de lectura para sistemas de lectura pesados. Pero no hay nada que decir que no puede tener un modelo de lectura específico de dominio que sea inmediatamente consistente.

El modelo de lectura inmediatamente consistente solo se usa para comprobar y recibir datos antes de emitir un comando (realmente es un servicio para el comando), nunca debe usarlo para mostrar directamente los datos de lectura a un usuario (es decir, de una solicitud GET web o similar). Utilice eventualmente modelos de lectura consistentes y escalables para eso.

Al igual que muchos otros, al implementar un sistema basado en fuentes de eventos, nos encontramos con el problema de singularidad.

Al principio era partidario de permitir que el cliente acceda al lado de la consulta antes de enviar un comando para averiguar si un nombre de usuario es único o no. Pero luego llegué a ver que tener un back-end que tiene cero validación de singularidad es una mala idea. ¿Por qué hacer cumplir cualquier cosa cuando es posible publicar un comando que corrompería el sistema ? Un back-end debe validar todos es la entrada de otra cosa que está abierto a los datos inconsistentes.

Lo que hicimos fue crear un index en el lado del comando. Por ejemplo, en el caso simple de un nombre de usuario que necesita ser único, simplemente cree un UserIndex con un campo de nombre de usuario. Ahora el lado del comando puede verificar si un nombre de usuario ya está en el sistema o no. Después de ejecutar el comando, es seguro almacenar el nuevo nombre de usuario en el índice.

Algo así también podría funcionar para el problema de descuento de pedidos.

El las ventajas son que el back-end del comando valida correctamente toda la entrada para que no se puedan almacenar datos inconsistentes.

Un inconveniente podría ser que necesita una consulta adicional para cada restricción de unicidad y está imponiendo complejidad adicional.

Creo que para tales casos, podemos usar un mecanismo como "bloqueo de aviso con vencimiento".

Ejemplo de ejecución:

• El nombre de usuario de Check existe o no en el modelo de lectura eventualmente consistente
• Si no existe; usando un almacenamiento o caché de redis-couchbase como keyvalue; intente insertar el nombre de usuario como campo de clave con algún vencimiento.
• Si tiene éxito; luego levante userRegisteredEvent.
• Si el nombre de usuario existe en el modelo de lectura o en el almacenamiento en caché, informe al visitante que nombre de usuario ha tomado.

Incluso puede usar una base de datos sql; insertar nombre de usuario como clave principal de alguna tabla de bloqueo; y luego un trabajo programado puede manejar vencimientos.

¿Ha considerado usar una caché "de trabajo" como una especie de confirmación de asistencia? Es difícil de explicar porque funciona en un poco de ciclo, pero básicamente, cuando un nuevo nombre de usuario es "reclamado" (es decir, se emitió el comando para crearlo), colocas el nombre de usuario en la caché con un vencimiento corto (lo suficientemente largo como para dar cuenta de otra solicitud que pasa por la cola y se denormaliza en el modelo de lectura). Si se trata de una instancia de servicio, entonces en memoria probablemente funcionaría, de lo contrario centralizarlo con Redis o algo.

Luego, mientras el siguiente usuario está llenando el formulario (suponiendo que haya un front end), usted verifica asíncronamente la disponibilidad del nombre de usuario en el modelo de lectura y alerta al usuario si ya está tomado. Cuando se envía el comando, se verifica la caché (no el modelo leído) para validar la solicitud antes de aceptar el comando (antes de devolver 202); si el nombre está en la caché, no acepte el comando, si no lo está, entonces se agrega a la caché; si se produce un error al agregarlo (duplicate key because some other process beat you to it), luego asume que el nombre es tomado then luego responde al cliente apropiadamente. Entre las dos cosas, no creo que haya muchas oportunidades para una colisión.

Si no hay un front end, puede omitir la búsqueda asincrónica o al menos hacer que su API proporcione el endpoint para buscarlo. Realmente no debería permitir que el cliente hable directamente con el modelo de comandos de todos modos, y colocar una API delante de él le permitiría haga que la API actúe como mediador entre el comando y los hosts de lectura.

Acerca de la unicidad, implementé lo siguiente:

• Un primer comando como "StartUserRegistration". UserAggregate se crearía sin importar si el usuario es único o no, pero con un estado de RegistrationRequested.

• En " UserRegistrationStarted "se enviaría un mensaje asíncrono a un servicio sin estado"UsernamesRegistry". sería algo así como "RegisterName".

• Servicio intentaría actualizar (sin consultas, "tell don't ask") tabla que incluiría una restricción única.

• Si tiene éxito, service respondería con otro mensaje (asíncrono), con una especie de autorización "UsernameRegistration", indicando que el nombre de usuario se registró correctamente. Puede incluir algún RequestId para realizar un seguimiento en caso de competencia concurrente (improbable).

• El emisor del mensaje anterior tiene ahora una autorización de que el nombre fue registrado por sí mismo, por lo que ahora puede marcar con seguridad el agregado de registro del usuario como exitoso. De lo contrario, marque como descartado.

Terminando:

• Este enfoque no implica consultas.

• El registro de usuario siempre se crearía sin validación.

• El proceso de confirmación implicaría dos mensajes asíncronos y una inserción de bd. La tabla no es parte de un modelo de lectura, sino de un servicio.

• Finalmente, un comando asíncrono para confirmar que el Usuario es válido.

• En este punto, un denormalizador podría reaccionar a un evento UserRegistrationConfirmed y crear un modelo de lectura para el usuario.