Autenticar usuario implementa Command en lugar de Query

[jeijei4]

La autenticación de usuario es de lectura, ¿Porqué lo crearon con Command en lugar de Query?

https://github.com/CodelyTV/php-ddd-example/blob/38159067018714cb37ab29274a2352d6611f4fb1/src/Backoffice/Auth/Application/Authenticate/

[Angelitorl]

La autenticación de usuario es de lectura, ¿Porqué lo crearon con Command en lugar de Query?

https://github.com/CodelyTV/php-ddd-example/blob/38159067018714cb37ab29274a2352d6611f4fb1/src/Backoffice/Auth/Application/Authenticate/

Este issue tiene mucho tiempo, pero comento mi opinión por si ayuda a alguien que acaba por aquí. Para empezar, es un punto bastante controvertido el de los login, ya que es una operación en la que necesitas leer (nos interesa usar una Query), pero también puedes estar aplicando un cambio en el estado de la aplicación, por ejemplo creando una sesión (ahora nos interesa usar un Command).

Por un lado necesitas que el método HTTP para la llamada al login /login sea un POST, ya que si es un GET podría ser cacheado por proxies; y otras opciones como PUT y demás directamente no tienen mucho sentido semántico.

Entiendo que en este caso simplemente han visto que al ser un POST esto debe ser un Command y a correr. También, por otras lecturas que he visto del equipo de Codely, buscarían "mapear" al cliente con un socket desde el que éste estaría esperando su sesión o token.

Una opción que creo que es válida, sobre todo si es un caso muy particular en nuestra aplicación, es utilizar el QueryBus a pesar de que el método HTTP sea un POST. Esto tiene especial sentido si utilizamos JWT, por ejemplo, ya que no estaríamos modificando el estado de la aplicación.
Lo más importante para este tipo de cosas es que dejemos bien documentadas estas excepciones para el resto del equipo y, además, asegurarnos de que efectivamente sigan siendo excepciones y no la norma.