25: PES 25 - Validamos. Pero, ¿Dónde?

En este os cuento acerca de una de las últimas entrevistas que hice(como entrevistador).

Normalmente, hacemos una prueba técnica(coding challenge) la cual consiste en hacer un pequeño servicio que cumple una serie de requerimientos a través de un REST API.

Intro a arquitecturas limpias, tienes una capa principal dónde está el dominio, que son los objetos que tendrán la lógica de negocio, yo cuando he trabajado con este tipo de arquitecturas, dominio y aplicación van de la mano, entonces, los casos de uso/servicios son los que están en el centro de la arquitectura, sólamente las piezas interiores conocen sobre las exteriores, como exteriores tenemos los repositorios, tenemos los controllers, etc, que conocen de los casos de uso pero no al revés, yo desde un caso de uso, no sé si me llama un controller ó un evento ó lo que sea, normalmente los dividimos por inbound/outbound, controller sería un inbound y repository sería un outbound.

La persona en cuestión tenía todas las validaciones dentro del objeto de la petición al servicio. Llegando a hacer saber al caso de uso acerca de JSON por ejemplo.

Tipos de validación : cliente(Front end), servidor(API, dominio)

Cliente: Validación de formularios, feedback usuario etc.

La API valida la forma del mensaje que se recibe, por ejemplo que una fecha sea una cadena ó que una cantidad sea un número, se podrían llegar a validar por ejemplo en el caso de una transferencia que la cantidad sea positiva, si eso tuviese sentido a la hora de exponer nuestro API.

El dominio, normalmente, valida las reglas de negocio, por ejemplo, si quieres hacer una transferencia, que tengas saldo suficiente, normalmente en cómo suelo montar las arquitecturas de los servicios, si necesitas acceder a la bbdd seguro que es una validación de dominio.

Recordad que podéis contactarme a través de https://remusrd.com.

Este episodio fue grabado en twitch: https://www.twitch.tv/remusrichard.