Refactorización
A continuación os describo la refactorización que he llevado a cabo:
- La prueba requería adaptar el controlador solicitado como una API REST. Por lo que, he deshabilitado los endpoints “create” y “edit” que venían definidos y pasaban los datos a la vista para que sus solicitudes HTTP envíen 404.
- Para esta prueba no he configurado ningún tipo de autenticación, pero sería bueno para un desarrollo posterior.
Para ello, podríamos usar el paquete Laravel Sanctum que proporciona un sistema de autenticación basado en tokens, con el que poder realizar las llamadas a la API enviando en el header:
authorization: Bearer {token}
Para la realización de la prueba he considerado lo siguiente:
Un lead es un cliente potencial, que a través de diversos medios de marketing puede convertirse en un cliente real. Los leads son personas que previamente han mostrado interés en tus productos o servicios a través de diferentes plataformas como tu sitio web, un evento, publicidad o redes sociales. Se trata de clientes en bruto y no de compradores de facto.
Pero debido a que no disponemos de la lógica de negocio necesaria para poder realizar un cálculo adecuado y tampoco tenemos histórico de las acciones que realizan los clientes, para tomar decisiones más concretas, he definido el cálculo del score en función de si el cliente proporciona o no el número de teléfono. Para ello, la herramienta generará automáticamente un número aleatorio. Cuyo valor será un número:
- entre 0 y 49.99: cuando el cliente no nos proporcione número de teléfono;
- y entre 50 y 99.99: cuando sí lo haga.
Cuanto mayor sea la puntuación, más interesante es el cliente, ya que significa que es más probable que realice una compra.
Por tanto, bajo esta definición, la API en la solicitud de creación (store) recibirá los datos del cliente y automáticamente generará el score. Mientras que en la solicitud de edición (update) se validará que el score que se intenta editar cumpla dichos requisitos.
Primeramente, he adaptado la estructura que nos proporciona Laravel, a una arquitectura de software basada en el patrón “Service-Repository”.
Esta arquitectura separa la lógica de la aplicación en dos partes: la capa de servicio y la capa de repositorio. La capa de servicio se encarga de la lógica de negocios y la capa de repositorio se encarga de la persistencia de datos.
La ventaja principal de este patrón es la separación clara de las diferentes responsabilidades en la aplicación y la facilidad de mantenimiento. Con este patrón, los cambios en la base de datos no afectan a la lógica de la aplicación y los cambios en la lógica de la aplicación no afectan a la capa de repositorio. Además, se mejora la modularidad y la reutilización del código.
La estructura de capas ha quedado de la siguiente forma:
Es el punto de entrada y salida de la aplicación. Es el encargado de recibir las solicitudes HTTP, llamar a sus correspondientes servicios para realizar las operaciones de negocio necesarias, procesar los datos obtenidos y devolver la respuesta adecuada a la capa de presentación.
Para realizar este ciclo a la hora de tratar los datos, el controlador se ayuda de otros niveles de capas, que defino a continuación:
Recibirá y validará los datos de entrada de una solicitud HTTP antes de que se envíen a los servicios correspondientes. Esta capa es responsable de validar la información de entrada recibida en un endpoint específico utilizando las reglas de validación definidas en el controlador para proteger la integridad de los datos en el sistema.
En esta capa se definirán las estructuras y formatos de los recursos que son expuestos por el servidor y consumidos por los clientes que solicitan información a través de la red. Es decir, es la capa de transformación que se encarga de estructurar y dar formato a los datos generados por los servicios antes de enviarlos al cliente. (Para esta prueba no la he usado, porque no ha sido necesaria)
Esta capa se encarga de enviar una respuesta estructurada y consistente a través de la red a los clientes que solicitan recursos del servidor. Es responsable de dar formato a los datos de salida generados por el servicio antes de enviarlos al cliente en un formato que pueda ser fácilmente consumido por el mismo.
La capa de servicio actúa como intermediario entre la capa de presentación y la capa de persistencia. Tiene como objetivo proveer una interfaz de alto nivel para la capa de presentación y garantizar una separación entre la lógica de negocios y la lógica de acceso a los datos.
La capa de repositorio proporciona una interfaz de bajo nivel para el acceso a la base de datos. Esta capa debe implementar todas las operaciones de acceso a los datos, como recuperar, actualizar y eliminar registros.
Para la definición del modelo de datos he decidido cambiar la relación que venía en el controlador proporcionando.
Considero que la tabla principal es “client” con los campos: “name”, “email” y “phone”, mientras que la tabla “leads” es la que llevará la relación 1to1 recibida del “client. Por lo que, tiene la clave foránea client_id y el valor del score. He creado una relación 1to1, porque aunque hubiera diferentes variables o indicadores para calcular el scoring, este debe tener un valor único para un cliente.
