Vistas y Modelos

Vista funcional - Modelo Componentes

En el siguiente diagrama se resaltan los componentes a los que se aplica una táctica o un patrón, y se resalta en morado el flujo de comunicación que estará involucrado en el experimento a realizar. En rojo se resalta el componente monitor introducido, en azul el detalle de la fachada implementada en el API Gateway, en verde, el estilo N-niveles, en naranja, la extracción del componente Evaluator, en lila, el componente API Gateway que se asociará al patrón Abierto-Cerrado y en celeste, el componente DB que se le asociará el patrón Singleton. El análisis y razonamiento de estos cambios se encuentra más abajo en este documento.

Vista despliegue - Modelo Despliegue

Se puede evidenciar en color rojo que el componente monitor va a ser desplegado en su propio contenedor, la lógica detalla de por qué se llevará a cabo de esta forma, se encuentra más abajo en el documento.

Vista Información - Modelo Información

Estilos

N-Niveles

Razonamiento

En este estilo, la aplicación se divide en varios niveles, cada una con una responsabilidad específica: 'Nivel de Presentación', 'Nivel de Acceso y Autorización', 'Nivel de Lógica de Negocio' y 'Nivel de Persistencia de Datos'. Cada nivel sólo puede interactuar con el nivel inmediatamente inferior, y se comunican a través de interfaces bien definidas. Esta restricción ayuda a mantener la separación de responsabilidades y hace que el sistema sea más modular, promoviendo una alta cohesión y un bajo acoplamiento, que consecuentemente favorece la latencia en el sistema. El 'Nivel de Presentación' se encarga de la interfaz de usuario, el 'Nivel de Acceso y Autorización' se encarga de permitir o rechazar las solicitudes de acuerdo a los permisos y accesos definidos, el 'Nivel de Lógica de Negocio' contiene las reglas de negocio de la aplicación, y el 'Nivel de Persistencia de Datos' se encarga de almacenar y recuperar los datos.

Tácticas

Acceso a los recursos - Dar prioridad a los eventos

Razonamiento

Decidimos implementar el componente candidate management para dar una prioridad a los eventos recibidos por parte de cierto tipo de usuarios en el sistema, esto con la finalidad de tratar aquellos de mayor importancia primero para poder garantizar el tiempo de respuesta.

El objetivo principal de este componente es aportar al cumplimiento de los ASR relacionados con latencia, en este caso:

Como aspirante, cuando presento una prueba, dado que el sistema opera normalmente, quiero que la siguiente pregunta (adaptada) sea devuelta en menos de 0.5 segundos

Accesso a los recursos - Limitar tiempo de ejecución

Razonamiento

Al implementar el componente evaluator además de llevar a cabo la evaluación de las pruebas de un candidato, se asignará un tiempo máximo de ejecución para responder a un evento recibido de forma que otros eventos puedan ser atendidos.

El objetivo principal de este componente es aportar al cumplimiento de los ASR relacionados con latencia, en este caso:

Como aspirante, cuando presento una prueba, dado que el sistema opera normalmente, quiero que la retroalimentación de la pregunta sea devuelta en menos de 0.3 segundos

Incremento de recursos - Mantener múltiples copias de la información.

Se implementó el componente DB con la finalidad de poder crear múltiples nodos para el mismo componente para no sufrir una degradación en el sistema en el caso de que múltiples eventos estén buscando tener acceso a determinada información del sistema.

El objetivo principal de este componente es aportar al cumplimiento de los ASR relacionados con latencia, en este caso:

Como administrador del sistema, cuando múltiples usuarios están enviando una prueba, dado que el sistema opera con alto tráfico, quiero el sistema soporte hasta 100 usuarios.

Detección de fallas - Monitoring

Razonamiento

Dado que el punto inicial de la aplicación es el middleware de autenticación y que todas las solicitudes pasarán por este punto, decidimos implementar el monitoring para verificar el estado general de la aplicación en cualquier momento, aportándonos también la facilidad de introducir al sistema la detección de fallas, la congestión del sistema o incluso ataques de denegación de servicios, que aunque no está dentro de los ASR priorizados en nuestro diseño queremos tenerlo en cuenta dentro de la solución.

El objetivo principal de este componente es aportar a la mitigación o cumplimiento de los ASR relacionados con disponibilidad, en este caso:

• Como administrador del sistema, cuando quiero saber el estado del sistema, dado que el sistema opera normalmente, quiero recibir una alerta en caso de que el componente de monitoreo detecte una falla en un tiempo no mayor a 10 segundos, teniendo en cuenta que el componente de monitoreo estará verificando el estado del sistema de autenticación en un intervalo de 5 segundos.

Patrones

Single Responsability

Razonamiento

Se implementa el patrón de single responsability al extraer la funcionalidad de evaluar pruebas del componente Candidate Management y asignar esa responsabilidad al componente Evaluator, el cual será el encargado de realizar las validaciones a las pruebas asignadas a un usuario. Por último, el componente Candidate Management tiene como una de sus responsabilidad principales el llevar a cabo la priorización de eventos recibidos para poder cumplir con la latencia esperada.

Facade

Razonamiento

Se utiliza el patron de diseño facade para proveer una interfaz unica (API Gateway) que sirve como intermediador para la comunicación con los subsistemas de autenticación, lógica de negocio y persistencia. En este caso, se crearon tres 'Routers': 'CandidateRouter', 'ProjectRouter' y 'CompanyRouter', que se encargan de administrar los diferentes componentes del sistema relacionados con los candidatos, los proyectos y las compañías, respectivamente. Esto se llevó a cabo debido a que se busca introducir un único punto de entrada al sistema mediante el cual los clientes se van a comunicar con los subsistemas mediante diferentes peticiones realizadas exclusivamente al API Gateway. El patrón Facade sirve como punto de protección a los subsistemas o componentes al reducir el numero de objetos con los cuales el cliente tiene que lidiar, por lo cual facilita la interacción con el sistema. Por último promueve un bajo acoplamiento entre el subsistema y los clientes que realizan las peticiones, promoviendo de esta forma una baja latencia en el sistema.

Abierto y Cerrado

Razonamiento

El patrón de abierto y cerrado se utilizó al implementar el API Gateway, esto debido a que los componentes de la lógica de negocio puede ser cambiados por nuevas implementaciones o pueden llegar a ser a ser reemplazados por nuevos componentes en el dado caso de que la lógica de negocio así lo requiera. Sin embargo la funcionalidad expuesta a los clientes no cambia debido a que las API no se modifican, cumpliendo de esta forma que el componente esté abierto a las extensiones pero cerrado a las modificaciones.

Singleton

Razonamiento

Se utiliza el patrón de singleton para mantener un solo componente de DB asociado a un solo nodo de ejecución para poder garantizar la consistencia y coherencia de los datos del sistema, si el sistema necesita escalar para poder evitar una degradación en los tiempos de respuesta, el patrón seguirá siendo de vital importancia debido a que se mantendrá una única instancia por nodo de ejecución. Este patrón también es utilizado en el componente Monitor, debido a que se mantiene una sola instancia del componente que puede ser replicada a multiples nodos de ejecución en caso de que se necesite un escalamiento en el sistema y de esta forma aumentar el atributo de observabilidad para poder monitorear algún otro componente.