Supongamos que tengo un sistema complejo donde hay grandes árboles de personas. Los pensamientos simples son relación entre empleados/gerente, muchos empleados reportan a un gerente. Ahora, además del gerente, hay personal de soporte que es capaz de actuar en nombre del gerente y puede manipular a los empleados de los gerentes.CQRS aplicando problemas de corte transversal, como la seguridad
En un sistema CQRS, ¿cómo modelaría un mensaje para una acción hipotética de "editar empleado" donde el invocador de la acción es un personal de soporte. La acción solo puede tener éxito si el miembro del personal según la relación de seguridad del gerente actúa sobre un empleado en su reino.
La verificación de la seguridad de esto implicaría consultar la base de datos para validar que la persona que se está modificando está de hecho dentro de la cadena de empleados de ese administrador.
¿Dónde ocurriría esta consulta? ¿Antes de originar el mensaje "editar empleado"?
Si los datos son validados por adelantado antes de originar el mensaje, en un sistema eventualmente consistente suponga que antes de que el mensaje "editar empleado" haya sido procesado se haya producido una acción separada que habría eliminado la autoridad del usuario para completar el " editar acción de los empleados. Si el controlador de comando no valida los problemas de seguridad de ese mensaje, el mensaje seguirá teniendo éxito aunque el usuario ya no tenga la autoridad para ejecutarlo.
Esto parece implicar que la validación de doble cara, similar a la validación de la interfaz de usuario & del lado del servidor, sería la mejor opción. Sin embargo, el método para completar esa validación parece que violaría los principios clave de CQRS.
¿Qué enfoque (es) son mejores cuando se tienen que tratar estos y otros asuntos similares al utilizar CQRS?
IMO no hay una respuesta general ... Siempre validaría en el lado del controlador de comandos * al menos * y ** opcionalmente ** "por adelantado" (que podría estar en la parte que acepta un mensaje en la cola)) – Yahia
También creo que es importante distinguir entre verdaderas preocupaciones transversales como la autenticación, la autorización simple (este usuario puede realizar una acción de este tipo), de las Reglas de negocio que rigen si se permite algo para una entidad específica. –