About arc42

arc42, the template for documentation of software and system architecture.

Template Version 8.2 EN. (based upon AsciiDoc version), January 2023

Created, maintained and © by Dr. Peter Hruschka, Dr. Gernot Starke and contributors. See https://arc42.org.

Note

This version of the template contains some help and explanations. It is used for familiarization with arc42 and the understanding of the concepts. For documentation of your own system you use better the plain version.

1. Introducción y Metas

Y es un juego de tablero abstracto para dos personas, jugado sobre un tablero triangular formado por casillas hexagonales. El objetivo es que, por turnos, cada jugador coloque fichas de su color hasta conseguir una cadena conectada de sus fichas que toque los tres lados del triángulo.Para lograr este objetivo se ha propuesto una solucion que consta de dos partes:

  • Una aplicación Web que ofrecerá a los usuarios la posibilidad de jugar a diferentes juegos Y, que estará implementada en Typescript. Esta aplicación también ofrecerá un API externo que permitirá que sea utilizada por bots.

  • Un módulo implementado en Rust que permitirá chequear si una partida ha sido ganada o no, así como sugerir el siguiente movimiento. Este módulo ofrecerá un interfaz de servicio web básico para que pueda ser invocado por la aplicación web.

Describes the relevant requirements and the driving forces that software architects and development team must consider. These include

  • underlying business goals,

  • essential features,

  • essential functional requirements,

  • quality goals for the architecture and

  • relevant stakeholders and their expectations

1.1. Vista general de los requisitos

Construir una plataforma web para jugar partidas del juego Y con soporte de usuarios, historial y una API para bots, apoyada por un módulo de lógica en Rust para validar formato YEN y verificar victoria.

1.1.1. MÓDULO 1: APLICACIÓN WEB (TYPESCRIPT)

RF01 - Gestión de Usuarios.

  • RF01.1: El sistema permitirá el registro de nuevos usuarios con email y contraseña.

  • RF01.2: El sistema permitirá el inicio de sesión de usuarios registrados.

  • RF01.3: El sistema mantendrá sesiones activas del usuario durante el uso.

  • RF01.4: El sistema permitirá a los usuarios cerrar sesión.

RF02 - Interfaz de Juego

  • RF02.1: El sistema proporcionará una interfaz web interactiva para jugar partidas de juegos tipo Y.

  • RF02.2: La interfaz mostrará el tablero de juego actualizado en tiempo real.

  • RF02.3: El sistema permitirá a los usuarios realizar movimientos mediante clics en el tablero.

  • RF02.4: La interfaz mostrará el turno actual del jugador.

  • RF02.5: El sistema notificará visualmente el resultado de la partida (victoria/derrota).

RF03 - Historial de Partidas

  • RF03.1: El sistema almacenará el historial de partidas completadas por cada usuario.

  • RF03.2: El sistema permitirá a los usuarios consultar sus partidas anteriores.

  • RF03.3: El sistema mostrará estadísticas básicas

    • RF03.3.1: El sistema mostrará las partidas ganadas

    • RF03.3.2: El sistema mostrará las partidas perdidas

RF04 - API Externa para Bots

  • RF04.1: El sistema expondrá una interfaz para permitir la integración con bots

  • RF04.2: La API permitirá crear nuevas partidas como bot.

  • RF04.3: La API permitirá realizar movimientos en partidas existentes.

  • RF04.4: La API devolverá el estado actual de la partida en formato YEN.

1.1.2. MÓDULO 2: MÓDULO DE LÓGICA (RUST)

RF05 - Verificación de Victoria

  • RF05.1: El módulo recibirá una representación de partida en formato YEN y determinará si existe un ganador.

  • RF05.2: El módulo identificará qué jugador ha ganado la partida.

  • RF06 - Servicio Web

    • RF06.1: El módulo permitirá verificar si una partida ha sido ganada.

    • RF06.2: Todas las respuestas del servicio serán en formato JSON.

RF07 - Procesamiento de Formato YEN

  • RF07.1: El módulo interpretará correctamente las partidas codificadas según la notación YEN.

  • RF07.2: El módulo validará que la notación YEN recibida sea correcta sintácticamente.

  • RF07.3: El módulo rechazará peticiones con formato YEN inválido con código de error apropiado.

Contents

Short description of the functional requirements, driving forces, extract (or abstract) of requirements. Link to (hopefully existing) requirements documents (with version number and information where to find it).

Motivation

From the point of view of the end users a system is created or modified to improve support of a business activity and/or improve the quality.

Form

Short textual description, probably in tabular use-case format. If requirements documents exist this overview should refer to these documents.

Keep these excerpts as short as possible. Balance readability of this document with potential redundancy w.r.t to requirements documents.

Further Information

See Introduction and Goals in the arc42 documentation.

1.2. Requisitos de Calidad

Atributo de calidad Motivación

Rendimiento (RNF01)

El sistema deberá soportar al menos 100 usuarios concurrentes.

Seguridad (RNF02)

Las comunicaciones entre módulos y con clientes deberán ir cifradas mediante HTTPS, y las contraseñas se almacenarán con hash seguro.

Disponibilidad (RNF03)

El sistema deberá tener una disponibilidad mínima del 99% en horario de operación.

Mantenibilidad (RNF04)

El código de ambos módulos deberá incluir pruebas unitarias con cobertura mínima del 70% y estar adecuadamente documentado.

Usabilidad (RNF05)

La interfaz web deberá ser responsive y funcionar correctamente en dispositivos móviles y desktop.

Interoperabilidad (RNF06)

La comunicación entre módulos deberá realizarse exclusivamente mediante JSON siguiendo la notación YEN.
Contents

The top three (max five) quality goals for the architecture whose fulfillment is of highest importance to the major stakeholders. We really mean quality goals for the architecture. Don’t confuse them with project goals. They are not necessarily identical.

Consider this overview of potential topics (based upon the ISO 25010 standard):

Categories of Quality Requirements
Motivation

You should know the quality goals of your most important stakeholders, since they will influence fundamental architectural decisions. Make sure to be very concrete about these qualities, avoid buzzwords. If you as an architect do not know how the quality of your work will be judged…​

Form

A table with quality goals and concrete scenarios, ordered by priorities

Contents

Explicit overview of stakeholders of the system, i.e. all person, roles or organizations that

  • should know the architecture

  • have to be convinced of the architecture

  • have to work with the architecture or with code

  • need the documentation of the architecture for their work

  • have to come up with decisions about the system or its development

Motivation

You should know all parties involved in development of the system or affected by the system. Otherwise, you may get nasty surprises later in the development process. These stakeholders determine the extent and the level of detail of your work and its results.

Form

Table with role names, person names, and their expectations with respect to the architecture and its documentation.

1.3. Stakeholders

Nombre Metas

Micrati

Empresa involucrada en el proyecto. Busca un producto final estable y mantenible, alineado con los requisitos acordados y con una integración correcta entre módulos.

Usuarios

Personas que usan la aplicación. Quieren una experiencia de juego fluida y clara, partidas fiables y acceso sencillo a su historial y estadísticas.

Equipo de desarrolladores

Desarrolladores encargados de construir y mantener el sistema. Buscan una arquitectura robusta, fácil de probar y evolucionar, con buen rendimiento y documentación que facilite el trabajo.

Profesores

Supervisores/asesores académicos del proyecto. Esperan una solución bien justificada y documentada, con buenas prácticas y cumplimiento verificable de los requisitos.

2. Restricciones de Arquitectura

Contents

Any requirement that constraints software architects in their freedom of design and implementation decisions or decision about the development process. These constraints sometimes go beyond individual systems and are valid for whole organizations and companies.

Motivation

Architects should know exactly where they are free in their design decisions and where they must adhere to constraints. Constraints must always be dealt with; they may be negotiable, though.

Form

Simple tables of constraints with explanations. If needed you can subdivide them into technical constraints, organizational and political constraints and conventions (e.g. programming or versioning guidelines, documentation or naming conventions)

Further Information

See Architecture Constraints in the arc42 documentation.

En este apartado se describen las restricciones de arquitectura que afectan a este proyecto. Estas restricciones pueden ser técnicas u organizativas y pueden incluir convenciones como directrices de programación, versionado, documentación o nomenclatura.

2.1. Restricciones Técnicas y Estructurales

Restricción Descripción

Control de Versiones

Usaremos Git y GitHub para el control de versiones del proyecto

Documentación

La documentación del proyecto estará basada en el formato arc42 y se alojará en GitHub Pages

Lenguajes de Programación

El proyecto se desarrollará principalmente en JavaScript. Además el motor del juego estará en Rust

Testing

Se utilizará Vitest para testing unitario y Cucumber para testing end-to-end

Apis Creadas

Se necesitarán APIs para la comunicación entre el frontend y el backend

Deployment

El despliegue del proyecto se hará en una máquina Linux con docker instalado creando un contenedor por cada módulo

2.2. Restricciones Organizativas

Restricción Descripción

Reuniones

Nos reuniremos todas las semanas los jueves de 10:00-11:00

GitHub issues

Los issues de GitHub se usarán para gestionar tareas y problemas del proyecto

3. Contexto y Alcanze

Contents

Context and scope - as the name suggests - delimits your system (i.e. your scope) from all its communication partners (neighboring systems and users, i.e. the context of your system). It thereby specifies the external interfaces.

If necessary, differentiate the business context (domain specific inputs and outputs) from the technical context (channels, protocols, hardware).

Motivation

The domain interfaces and technical interfaces to communication partners are among your system’s most critical aspects. Make sure that you completely understand them.

Form

Various options:

  • Context diagrams

  • Lists of communication partners and their interfaces.

Further Information

See Context and Scope in the arc42 documentation.

3.1. Contexto de Negocio

Micrati quiere lanzar YOVI, una conunto de juegos basados en el juego Y, accesibles desde la web. El sistema debe permitir que personas jueguen partidas del juego Y desde un frontend web, incluyendo al menos la versión clásica (humano vs máquina) con tamaño de tablero variable. Además, el juego contra la computadora debe ofrecer más de una estrategia seleccionable por el usuario.

Diagrama de contexto de negocio

Actor

Cómo interactúa

Usuarios

Acceden a YOVI desde la aplicación web para jugar y registrarse.

Bots

Invocan la API externa de YOVI enviando la posición en JSON y reciben el siguiente movimiento en YEN.

Aplicación YOVI

Recibe peticiones de Usuarios y Bots llama al servicio de lógica en Rust y persiste/consulta datos en la base de datos para histórico/estadísticas.
Contents

Specification of all communication partners (users, IT-systems, …​) with explanations of domain specific inputs and outputs or interfaces. Optionally you can add domain specific formats or communication protocols.

Motivation

All stakeholders should understand which data are exchanged with the environment of the system.

Form

All kinds of diagrams that show the system as a black box and specify the domain interfaces to communication partners.

Alternatively (or additionally) you can use a table. The title of the table is the name of your system, the three columns contain the name of the communication partner, the inputs, and the outputs.

3.2. Contexto Técnico

Contents

Technical interfaces (channels and transmission media) linking your system to its environment. In addition a mapping of domain specific input/output to the channels, i.e. an explanation which I/O uses which channel.

Motivation

Many stakeholders make architectural decision based on the technical interfaces between the system and its context. Especially infrastructure or hardware designers decide these technical interfaces.

Form

E.g. UML deployment diagram describing channels to neighboring systems, together with a mapping table showing the relationships between channels and input/output.

Diagrama de contexto técnico

Actor

Cómo interactúa

Usuario

Accede a YOVI mediante la UI Web para jugar y registrarse.

Bot

Consume el API de YOVI puede jugar contra la aplicación invocando play(position) y recibiendo el movimiento en notación YEN.

Aplicación YOVI

Recibe peticiones del Usuario y del Bot, invoca al Servicio de lógica por HTTP/HTTPS intercambiando JSON (partida en YEN) y gestiona persistencia contra la base de datos.

Servicio de lógica

Expone un servicio web básico invocado por YOVI, verifica si la partida está ganada y sugiere el siguiente movimiento, usando JSON en notación YEN.

Base de datos

Almacena usuarios, partidas e histórico y recibe operaciones de lectura/escritura desde YOVI para persistir y consultar histórico/estadísticas.

4. Estrategia de Solución

Contents

A short summary and explanation of the fundamental decisions and solution strategies, that shape system architecture. It includes

  • technology decisions

  • decisions about the top-level decomposition of the system, e.g. usage of an architectural pattern or design pattern

  • decisions on how to achieve key quality goals

  • relevant organizational decisions, e.g. selecting a development process or delegating certain tasks to third parties.

Motivation

These decisions form the cornerstones for your architecture. They are the foundation for many other detailed decisions or implementation rules.

Form

Keep the explanations of such key decisions short.

Motivate what was decided and why it was decided that way, based upon problem statement, quality goals and key constraints. Refer to details in the following sections.

Further Information

See Solution Strategy in the arc42 documentation.

En este apartado se describen las decisiones fundamentales y estrategias de solución que dan forma a la arquitectura del sistema. Estas decisiones incluyen:

4.1. Decisiones Tecnológicas

Decisión Descripción

Base de datos

Usaremos MySQL debido a su compatibilidad con el entorno de desarrollo y su robustez para manejar datos estructurados. Además, es una base de datos ampliamente utilizada y entendida por el equipo de desarrollo.

Visual Studio Code

Usaremos Visual Studio Code como editor de código principal para su compatibilidad con el entorno de desarrollo y su extensibilidad.

Express

Usaremos Express como framework para el backend del módulo de users debido a su simplicidad.

PlantUML

Usaremos PlantUML para la creación de diagramas de arquitectura debido a su facilidad de uso y su capacidad para integrarse con otras herramientas.

React y Node.js

Usaremos React para el desarrollo del frontend debido a su capacidad para crear interfaces de usuario interactivas y dinámicas, y Node.js para el backend por su eficiencia en la gestión de solicitudes y su compatibilidad con JavaScript.

4.2. Decisiones para lograr los requisitos de calidad

Decisión Descripción

Usabilidad

La usabilidad del sistema se logrará mediante una interfaz intuitiva y fácil de usar, siguiendo buenas prácticas de diseño de experiencia de usuario.

Accesibilidad

La accesibilidad del sistema se logrará mediante el cumplimiento de estándares de accesibilidad web, garantizando que todos los usuarios puedan interactuar con el sistema sin barreras.

Rendimiento

El rendimiento del sistema se logrará mediante el uso de tecnologías eficientes y optimización del código, asegurando una respuesta rápida y fluida del sistema.

Disponibilidad

La disponibilidad del sistema se logrará mediante la implementación de mecanismos de redundancia y recuperación ante fallos, garantizando que el sistema esté disponible para los usuarios en todo momento.

Seguridad

La seguridad del sistema se logrará mediante la implementación de medidas de seguridad robustas, como autenticación y autorización adecuadas.

Interoperabilidad

La interoperabilidad del sistema se logrará mediante el uso de estándares abiertos y protocolos de comunicación comunes, facilitando la integración con otros sistemas.

4.3. Decisiones Organizativas

  • Los miembros del grupo, ademas de las reuniones semanales que se celebren, mantendrán una comunicación constante a través de whatsapp y se podrán realizar reuniones adicionales si se considera necesario.

  • Se usará github con diferentes ramas para el desarrollo del proyecto, cada miembro del grupo se encargará de una parte del proyecto, aunque se fomentará la colaboración entre todos los miembros para asegurar la calidad del código y la integración de las diferentes partes del proyecto.

5. Vista de bloques de construcción

Content

The building block view shows the static decomposition of the system into building blocks (modules, components, subsystems, classes, interfaces, packages, libraries, frameworks, layers, partitions, tiers, functions, macros, operations, data structures, …​) as well as their dependencies (relationships, associations, …​)

This view is mandatory for every architecture documentation. In analogy to a house this is the floor plan.

Motivation

Maintain an overview of your source code by making its structure understandable through abstraction.

This allows you to communicate with your stakeholder on an abstract level without disclosing implementation details.

Form

The building block view is a hierarchical collection of black boxes and white boxes (see figure below) and their descriptions.

Hierarchy of building blocks

Level 1 is the white box description of the overall system together with black box descriptions of all contained building blocks.

Level 2 zooms into some building blocks of level 1. Thus it contains the white box description of selected building blocks of level 1, together with black box descriptions of their internal building blocks.

Level 3 zooms into selected building blocks of level 2, and so on.

Further Information

See Building Block View in the arc42 documentation.

5.1. Visión general del sistema

Here you describe the decomposition of the overall system using the following white box template. It contains

  • an overview diagram

  • a motivation for the decomposition

  • black box descriptions of the contained building blocks. For these we offer you alternatives:

    • use one table for a short and pragmatic overview of all contained building blocks and their interfaces

    • use a list of black box descriptions of the building blocks according to the black box template (see below). Depending on your choice of tool this list could be sub-chapters (in text files), sub-pages (in a Wiki) or nested elements (in a modeling tool).

  • (optional:) important interfaces, that are not explained in the black box templates of a building block, but are very important for understanding the white box. Since there are so many ways to specify interfaces why do not provide a specific template for them. In the worst case you have to specify and describe syntax, semantics, protocols, error handling, restrictions, versions, qualities, necessary compatibilities and many things more. In the best case you will get away with examples or simple signatures.

Vision general
Motivación

Visión general del sistema donde el usuario interactua con la aplicación. Esta hace uso del módulo gamey para validar movimientos y detemrinar cuando finaliza el juego. La separación entre WebApp y Gamey permite desacoplar la interfaz de usuario de la lógica del juego y del bot, facilitando el mantenimiento, extensión y reutilización de cada componente.

Componentes
Nombre Responsabilidad

User

 Interactua con la aplicación.

WebApp

 Gestiona la interacción del usuario con el sistema.

Gamey

 Gestiona la lògica del juego, el bot, los movimientos, …​

user-service

Comunica el front-end con el back-end Node siguiendo el protocolo HTTP y con el formato JSON. Expone una serie de operaciones para almacenar información de relevancia en la BD. Entre toda esa información, se encuentra:

  • Registro de usuarios.

  • Inicio de partidas.

  • Consulta de puntuaciones. …​

BotServer

Comunica el bot con el resto de la aplicación siguiendo el protocolo HTTP y con el formato JSON. La única operación que contempla es la realización de movimientos por parte del bot.

GameServer

Expone el método play para determinar la validez de una jugada realizada por los usuarios y determinar si la jugada permite ganar la partida actua..

Insert your explanations of black boxes from level 1:

If you use tabular form you will only describe your black boxes with name and responsibility according to the following schema:

Name Responsibility

<black box 1>

 <Text>

<black box 2>

 <Text>

If you use a list of black box descriptions then you fill in a separate black box template for every important building block . Its headline is the name of the black box.

5.2. Nivel 2 del sistema

Visión específica del módulo Yovi del sistema y las responsabilidades de los distintos subsistemas existentes en este.

Nivel 2
Componentes
Nombre Responsabilidad

Usuario

 Interactua con la aplicación.

WebApp

 Expone una interfaz de usuario para que el usuario interacciona con el sistema.

user-service

Comunica el front-end (WebApp) con el back-end Node (Users).

Users

 Gestiona la interacción con la base de datos.

Database

 Almacena un historial de los usuarios registrados, partidas realizadas, puntuaciones obtenidas, …​

Bot

 Contiene la lógica de los bots.

BotServer

 Permite la interacción del sistema con los bots.

Core

 Contiene la lógica del juego y gestiona el estado del mismo y la validación de movimientos y reglas.

GameServer

 Permite la interacción del sistema con la lógica del juego.

Notation

 Incluye toda la lógica sobre la notación YEN.

Here you describe <black box 1> according the the following black box template:

  • Purpose/Responsibility

  • Interface(s), when they are not extracted as separate paragraphs. This interfaces may include qualities and performance characteristics.

  • (Optional) Quality-/Performance characteristics of the black box, e.g.availability, run time behavior, …​.

  • (Optional) directory/file location

  • (Optional) Fulfilled requirements (if you need traceability to requirements).

  • (Optional) Open issues/problems/risks

Here you can specify the inner structure of (some) building blocks from level 1 as white boxes.

You have to decide which building blocks of your system are important enough to justify such a detailed description. Please prefer relevance over completeness. Specify important, surprising, risky, complex or volatile building blocks. Leave out normal, simple, boring or standardized parts of your system

…​describes the internal structure of building block 1.

Here you can specify the inner structure of (some) building blocks from level 2 as white boxes.

When you need more detailed levels of your architecture please copy this part of arc42 for additional levels.

Specifies the internal structure of building block x.1.

5.3. Nivel 3 del sistema

Visión más detallada de los subcomponentes internos de los bloques principales definidos en el nivel 2. En este nivel se describen las partes concretas que forman la interfaz web, el backend de usuarios y el motor de juego.

Nivel 3
Motivación

Este nivel permite mostrar la estructura interna de los módulos más importantes del sistema con mayor precisión. Así se entiende mejor cómo se organiza el código y cómo se separan responsabilidades entre presentación, servicios, persistencia y lógica de dominio.

La descomposición facilita el mantenimiento, porque cada bloque queda aislado en una responsabilidad concreta. También ayuda a documentar los puntos más relevantes para evolución futura y para entender dependencias entre distintos módulos.

Componentes
Nombre Responsabilidad

pages

Contiene las pantallas principales de la aplicación web y coordina la vista con los servicios.

components

Agrupa componentes reutilizables de interfaz como el tablero de juego, distintos menús, …​

services

Centraliza las llamadas a APIs y la lógica de comunicación con el backend y el motor de juego.

store

Gestiona el estado actual de la sesión del usuario y del tablero en un momento de una partida.

parsers

Transforma el estado de una partida a formato YEN.

header

Define la cabeceras de las distintas páginas diseñadas en React.

auth

Gestiona autenticación y registro de usuarios en el sistema.

database

Define el esquema y gestiona las conexiones con la base de datos del sistema.

middleware

Intercepta peticiones para validación, seguridad y control de flujo.

repositories

Encapsula el acceso a datos y abstrae la persistencia.

services

Permite interactuar con la base de datos haciendo uso de los repositorios.

monitoring

Proporciona trazabilidad, métricas y supervisión del servicio.

bot

Contiene la lógica específica de los distintos bots.

bot_server

Expone la funcionalidad de los bots como servicio.

core

Implementa las reglas del juego, el estado y la validación de movimientos.

game_server

Expone las operaciones principales para validar movimientos.

notation

Convierte y procesa la notación YEN.

6. Vista de Ejecución (Runtime View)

6.1. Resumen

Este documento describe los escenarios de ejecución más relevantes del sistema YOVI y las interacciones entre sus subsistemas principales: la Aplicación Web (Typescript) y el módulo de lógica en Rust (gamey). El intercambio entre ambos usa JSON en notación YEN para representar posiciones y movimientos.

6.2. Escenario 1 — Usuario humano juega contra la máquina (flujo principal)

Propósito: mostrar la interacción típica cuando un usuario desde la web juega contra un bot.

Actores:

  • Usuario (navegador)

  • Webapp — webapp/src/App.tsx

  • Servicio de bots / lógica (Rust) — gamey

Flujo (pasos):

  1. Usuario inicia una partida en la UI y selecciona "Jugar vs Máquina" y la estrategia (ej. random).

  2. La web prepara la posición inicial en notación YEN y la mantiene como estado local.

  3. Usuario hace un movimiento; la web lo muestra en el tablero.

  4. Webapp manda un post con body JSON con la notación YEN del nuevo estado.

  5. El servicio Rust recibe el YEN, lo parsea a GameY y valida la posición.

  6. Se invoca al bot y se calcula la respuesta.

  7. El servicio devuelve el movimiento en notación YEN; la web lo aplica al tablero y los datos de partida.

  8. Se repite 3-7 hasta que se finaliza el juego. Una vez se finaliza, muestra el resultado al jugador y se guardan las estadísticas del juego.

6.3. Escenario 2 — Bot externo invoca API "play" (integración con terceros, se juega una partida en otro servidor con nuestro bot)

Propósito: describir cómo clientes externos (bots/servicios) usan la API pública para solicitar movimientos.

Actores: - Cliente bot externo - API de comunicación - GameY

Flujo: 1. Cliente prepara un JSON en notación YEN describiendo la posición en un parámetro position y hace GEt la API de nuestro servidor 2. Se envía la notación YEN a GameY; si es válido se invoca al bot para que calcule el proximo movimiento. 3. Respuesta: En formato YEN en JSON. Contiene el estado del tablero tras realizar el movimiento.

Flujo altenativo 1:

3* YEN inválido → Se devuelve la peticion en estado de error y con cuerpo explicativo

Flujo alternativo 2:

3* Bot solicitado no reconocido → Se devuelve la peticion en estado de error y con cuerpo explicativo

6.4. Escenario 3 — Humano vs Humano (partida local por turnos)

Propósito: describir la interacción típica cuando dos jugadores comparten la misma instancia de la Webapp y juegan por turnos en el mismo dispositivo o en la misma sesión del navegador.

Actores:

  • Jugador A (navegador)

  • Jugador B (mismo navegadors)

  • Webapp

  • GameY

Flujo (pasos):

  1. Un jugador crea o inicia una partida local en la web y define el tamaño del tablero y opciones

  2. La web inicializa la posición en notación YEN y la mantiene como estado compartido entre turnos.

  3. Jugador A realiza su movimiento en el tablero; la web serializa la posición resultante a notación YEN y envía una petición POST al servicio GameY para validar/aplicar la jugada.

  4. El servicio Rust (GameY) recibe el YEN, valida la jugada con las reglas completas y devuelve la respuesta al frontend

  5. La web, al recibir la confirmación, aplica el estado devuelto al tablero y muestra que es el turno del Jugador B; la web no aplica reglas complejas por su cuenta.

  6. Jugador B realiza su jugada y se repite 3–5 alternando hasta que se detecta una condición de victoria.

  7. Al finalizar la partida, la web envía el resultado al backend para persistencia y estadísticas

Flujo alternativo: 4* El servicio Rust no valida la jugada por no ser válida. Se devuelve esta respuesta al frontend 5* El frontend informa al jugador, deshace la jugada y vuelve a 3.

7. Diagrama de despliegue

Content

The deployment view describes:

  1. technical infrastructure used to execute your system, with infrastructure elements like geographical locations, environments, computers, processors, channels and net topologies as well as other infrastructure elements and

  2. mapping of (software) building blocks to that infrastructure elements.

Often systems are executed in different environments, e.g. development environment, test environment, production environment. In such cases you should document all relevant environments.

Especially document a deployment view if your software is executed as distributed system with more than one computer, processor, server or container or when you design and construct your own hardware processors and chips.

From a software perspective it is sufficient to capture only those elements of an infrastructure that are needed to show a deployment of your building blocks. Hardware architects can go beyond that and describe an infrastructure to any level of detail they need to capture.

Motivation

Software does not run without hardware. This underlying infrastructure can and will influence a system and/or some cross-cutting concepts. Therefore, there is a need to know the infrastructure.

Form

Maybe a highest level deployment diagram is already contained in section 3.2. as technical context with your own infrastructure as ONE black box. In this section one can zoom into this black box using additional deployment diagrams:

  • UML offers deployment diagrams to express that view. Use it, probably with nested diagrams, when your infrastructure is more complex.

  • When your (hardware) stakeholders prefer other kinds of diagrams rather than a deployment diagram, let them use any kind that is able to show nodes and channels of the infrastructure.

Further Information

See Deployment View in the arc42 documentation.

Para representar de la manera más exacta y representativa posible el despliegue de nuestro sistema en la máquina virtual creada para la realización de las prácticas, se especifican dos niveles de infraestructura, con el fin ofrecer distintos puntos de vista del sistema: uno más general que represente los módulos más característicos de nuestro sistema, y otro más específico en el que aparecen los distintos contenedores encargados de la monitorización del mismo.

7.1. Nivel de infraestructura 1

Describe (usually in a combination of diagrams, tables, and text):

  • distribution of a system to multiple locations, environments, computers, processors, .., as well as physical connections between them

  • important justifications or motivations for this deployment structure

  • quality and/or performance features of this infrastructure

  • mapping of software artifacts to elements of this infrastructure

For multiple environments or alternative deployments please copy and adapt this section of arc42 for all relevant environments.

Diagrama de despliegue
Descripción

La aplicación se despliega sobre un servidor de Azure, en el que cada módulo que constituye el sistema se encuentra encapsulado en un contenedor de Docker.

El usuario interactua con el sistema a través del módulo WebApp, que no es más que una interfaz gráfica diseñada en React. El front-end a su vez se comunica con los dos back-ends del sistema mediante peticiones HTTP: Users y Gamey. Cada uno de ellos expone una serie de endpoints para realizar diferentes tareas, ya sea consultar la base de datos y almacenar/devolver la información relevante de nuestro sistema (módulo Users) o actuar como motor de juego (módulo Rust).

A su vez, el módulo Users mantiene una comunicación directa con nuestra base de datos relacional MySQL. La base de datos tiene un volumen asociado para permitir que los datos de nuestro sistema persistan una vez se despliegue el mismo.

Características de calidad/rendimiento

El hecho de emplear Docker para encapsular cada uno de los módulos del sistema en distintos contenedores permite que el sistema sea escalable y portable. Además, la separación de las distintas partes en distintos contenedores facilita el mantenimiento y la extensibilidad. Además, aumenta el rendimiento en comparación con emplear un contendor aislado, ya que se permite aislar las dependencias de cada módulo. Por otro lado, el uso de Docker permite el despliegue continuo de nuestra aplicación.

El despliegue automático desde GitHub Actions favorece tiempos de entrega cortos (en comparación al empleo de otras tecnologías) y una actualización uniforme de los servicios desplegados.

Mapeo de los bloques de construcción a infraestructura
Nombre Descripción

Azure VM (Linux Ubuntu 24.04)

Máquina virtual que actúa como servidor de la aplicación y sobre la que se despliega toda la infraestructura del sistema.

Docker

Entorno de ejecución que aísla cada módulo del sistema en distintos contenedores.

WebApp

 Front-end desarrollado en React que permite la interación con el usuario y se comunica directamente con los back-ends del sistema a través de sus correspondientes API REST.

Users

Back-end desarrollado en Node.js para gestionar la información relevante del sistema (información del usuario, resultado de partidas, …​) y que interactua con la base de datos del sistema.

Gamey

Back-end Rust que actúa como motor de juego y expone una API REST.

Database

Base de datos MySQL que almacena la información de valor de la app (usuarios, resultados, …​)

Here you can include the internal structure of (some) infrastructure elements from level 1.

Please copy the structure from level 1 for each selected element.

7.2. Nivel de infraestructura 2

Nivel de infraestructura 2
Descripción

En este nivel de infraestructura aparecen los módulos destinados a la monitorización del sistema, concretamente, los módulos Grafana y Prometheus.

El módulo Prometheus observa constantemente las APIs REST de los back-ends del sistema con el fin de recopilar estadísticas acerca del número de peticiones que reciben cada una de estas en cada instante, el tiempo de respuesta, …​ Todos estos datos se alamcenan en bases de datos volátiles que crea y elimina el propio Prometheus cuando el sistema se sistema se levanta o se tumba respectivamente; por lo tanto, la información no persiste.

Por otro lado, el contenedor Grafana accede a los datos extraidos por el módulo Prometheus con el fin de reprensentarlos gráficamente y poder comprender de manera visual el comportamiento de las diferentes APIs del sistema.

Además, es necesario mencionar la existencia del contenedor Swagger, destinado a desplegar la documentación sobre las diferentes APIs mencionadas anteriormente: endpoints existentes en cada una, acción asociada a cada uno de estos, URLs, …​ De esta manera, los desarrollados no tienen que acudir directamente al código (y desperdiciar demasiado tiempo comprendiendo el mismo) para enteder el funcionamiento de las mismas y los distintos servicios que ofrecen.

Características de calidad/rendimiento

La presencia de Prometheus y Grafana añade observabilidad al entorno, permitiendo monitorizar el comportamiento de la aplicación y detectar incidencias de forma más rápida.

Por otro lado, la inclusión de Swagger centraliza la documentación de las APIs de Users y Gamey, reduciendo la fricción durante el desarrollo y facilitando la incorporación de nuevos miembros al equipo. Además permite liberar a las APIS que tienen los servicios de la carga de mostrar la documentación, mejorando el rendimiento.

Mapeo de los bloques de construcción a infraestructura
Nombre Descripción

Prometheus

Herramienta de monitorización que recopila métricas de los servicios de la aplicación y los almacena en bases de datos temporales.

Grafana

Herramienta de visualización que consume Prometheus como datasource para mostrar dashboards con las métricas del sistema.

Swagger

Contenedor destinado a mostrar la documentación asociada a cada una de las APIs del sistema (Users y Gamey).

8. Conceptos Transversales (Cross-cutting Concepts)

8.1. Resumen

Esta sección recoge decisiones y reglas que aplican a varios bloques de YOVI al mismo tiempo. Su objetivo es mantener coherencia funcional y técnica entre interfaz web, servicios backend, motor de juego y operación en contenedores.

Concepto transversal Idea clave

Modelo canónico del juego

La notación YEN es la representación común del estado de partida entre frontend y motor.

Validación centralizada de reglas

La UI no decide legalidad ni victoria: delega en Gamey para evitar duplicidad de lógica.

Arquitectura poliglota orientada a responsabilidades

React/Node priorizan UX e I/O; Rust prioriza cálculo determinista y robustez de reglas.

Puntuación y ranking trazables

La puntuación se calcula de forma explícita y el ranking usa criterios estables y paginación.

Bots como servicio desacoplado

Las estrategias de bot se exponen por API y pueden evolucionar sin romper la UI.

Seguridad por tokens

Se usa JWT para autenticación de operaciones sensibles y flujo de refresco de sesión.

Portabilidad de datos entre entornos

En local se usa MySQL en Docker; en despliegue se configura host externo por variables de entorno.

8.2. Conceptos de dominio

8.2.1. YEN como lenguaje ubicuo

YOVI usa YEN como contrato de dominio compartido para representar partida, turno, jugadores y layout. Esta decisión evita traducciones ambiguas entre capas y permite que el mismo estado se valide igual en todos los componentes.

Reglas derivadas:

Toda integración entre frontend y motor intercambia estado en JSON YEN. Las transformaciones de coordenadas se realizan en los bordes (UI/servicio), no en el núcleo de reglas. El motor es la referencia final de validez de jugada.

8.3. Conceptos de UX y consistencia funcional

8.3.1. SPA con estado local y confirmación de servidor

La Webapp ofrece respuesta inmediata en interfaz, pero la consistencia fuerte de reglas se obtiene al confirmar la jugada con Gamey. Este patrón equilibra fluidez y corrección.

Reglas derivadas:

La interacción visual es optimista, pero el estado confirmado es el devuelto por backend/motor. En jugadas inválidas, se informa al usuario y no se consolida el turno. El frontend mantiene separadas lógica visual y reglas del juego.

8.4. Conceptos de seguridad

8.4.1. Autenticación con JWT y control de sesión

El servicio de usuarios emite access token y refresh token para autenticar llamadas. Operaciones de escritura relevantes (como registrar partida finalizada) exigen token válido.

Reglas derivadas:

El cliente debe enviar token de acceso en cabecera Authorization. El flujo de refresh rota tokens de refresco para reducir reutilización. Las credenciales de base de datos y secretos se inyectan por entorno, no en código fuente. Nota de implementación actual:

El mecanismo de sesión de refresh está implementado en memoria del proceso, útil para entorno de desarrollo y pruebas, pero no ideal para escalado horizontal sin almacenamiento compartido.

8.5. Conceptos de arquitectura y patrones

8.5.1. Control por modulos y responsabilidades

La solución separa claramente I/O y experiencia de usuario de la lógica de juego:

Webapp y servicio Users gestionan interacción, autenticación, persistencia y contratos HTTP. Gamey concentra validación de reglas y cálculo de jugadas/bots.

Beneficio arquitectónico:

Evolucionar reglas o estrategias de bot no obliga a rediseñar frontend. Cambios de UX o API no requieren reescribir núcleo algorítmico.

8.5.2. APIs explícitas y contratos estables

Cada capacidad se expone por endpoints definidos y estructuras de entrada/salida conocidas. Esto permite pruebas de integración más robustas y facilita uso por clientes externos.

8.6. Conceptos de puntuación y ranking

8.6.1. Modelo de puntuación (score) del sistema

La puntuación de partida se calcula de forma determinista con dos factores:

Tamaño de tablero. Número de turnos usados. Fórmula implementada:

score = (boardSize * 10) + max(0, 50 - turnNumber) Implicaciones:

Tableros mayores elevan puntuación base. Resolver en menos turnos mejora puntuación. La fórmula evita valores negativos en el término de eficiencia.

8.6.2. Modelo de ranking

El ranking global ordena usuarios por mejor puntuación y aplica criterios de desempate estables. El sistema soporta paginación controlada para evitar respuestas excesivas.

Reglas derivadas:

Page size permitido: 25, 50 o 100. Se ofrecen endpoints de leaderboard global, perfil, historial y vista centrada en usuario. El histórico separa partidas 1vsbot y 1vs1 para análisis funcional más claro.

8.7. Conceptos de bots y dificultad

8.7.1. Bots como capacidad transversal del sistema

El motor Gamey expone bots como un servicio HTTP, desacoplando la estrategia de juego de la capa de presentación. Esto habilita:

  • Juego humano vs. bot en la WebApp.

  • Consumo potencial por clientes externos o bots de terceros.

Estrategias y niveles

  • random_bot

  • medium_bot

  • hard_bot

Mapeo de dificultad desde el frontend

  • Fácil → random_bot

  • Media → medium_bot

  • Difícil → hard_bot

Reglas derivadas

  • La dificultad seleccionada por el usuario se traduce a un identificador de bot.

  • Si un bot no existe o no puede realizar un movimiento, la API devuelve un error explícito.

  • El motor valida que la partida no esté finalizada antes de sugerir una jugada.

8.8. Conceptos de datos y despliegue

8.8.1. Persistencia local vs despliegue

Se distinguen dos escenarios operativos:

Desarrollo local: MySQL en Docker Compose, inicializado por script SQL y volumen persistente. Despliegue: base de datos configurable por variables de entorno (host/usuario/clave/nombre), permitiendo usar base de datos externa en Azure en lugar del contenedor local. Consecuencia arquitectónica:

El servicio Users no depende rígidamente de un único proveedor local; depende de parámetros de conexión. El contenedor MySQL es una comodidad de desarrollo e integración, no una obligación de producción.

8.9. Conceptos de desarrollo y operación

8.9.1. Reproducibilidad y observabilidad

El sistema prioriza entorno reproducible con contenedores y añade piezas de monitorización para operación:

Arranque de servicios coordinado por Docker Compose. Configuración de Prometheus y Grafana para métricas. Separación de componentes para facilitar pruebas, despliegue y mantenimiento.

8.9.2. Calidad y pruebas como concepto transversal

La estructura de pruebas cubre frontend, backend Node y backend Rust, incluyendo pruebas de integración y e2e. Esto refuerza la trazabilidad entre decisiones de arquitectura y comportamiento real del sistema.

9. Decisiones arquitectónicas

9.1. Enfoque y alcance

Este apartado registra decisiones arquitectónicas relevantes, con impacto transversal, coste de cambio elevado o riesgo técnico significativo. Se documentan únicamente decisiones aceptadas y aplicadas en el repositorio actual.

Además, se reconoce explícitamente el contexto de partida del proyecto: la base inicial del laboratorio fue aportada por profesorado (principalmente en commits iniciales), y posteriormente el equipo evolucionó esa base con nuevas funcionalidades, seguridad, pruebas, observabilidad y mejoras de dominio.

9.2. Resumen de decisiones aceptadas

ID Decisión Estado Impacto principal

ADR-00

Adoptar y evolucionar una base inicial de laboratorio en lugar de rehacer desde cero.

Aceptada

Aceleró el arranque, pero exigió refactorización y endurecimiento progresivo.

ADR-01

Usar notación YEN como formato canónico de intercambio entre componentes.

Aceptada

Interoperabilidad estable entre frontend, backend y motor.

ADR-02

Separar responsabilidades en tres componentes: Webapp, Users y Gamey.

Aceptada

Mayor mantenibilidad, despliegue independiente y desacoplamiento tecnológico.

ADR-03

Implementar reglas, validación y bots del juego Y en Rust (Gamey), dejando la UI sin reglas de victoria.

Aceptada

Coherencia funcional y menor duplicidad de lógica crítica.

ADR-04

Exponer API de juego versionada para bots y jugadas (rutas con versión v1).

Aceptada

Evolución controlada de contrato para integraciones externas.

ADR-05

Adoptar autenticación JWT con acceso corto + refresh y revocación/rotación.

Aceptada

Mejora de seguridad de sesiones en API.

ADR-06

Mantener dos topologías operativas de base de datos: local de desarrollo y despliegue en infraestructura Azure.

Aceptada

Reproducibilidad local y flexibilidad en producción sin acoplarse a una única topología.

ADR-07

Definir puntuación determinista y ranking persistido (histórico, perfil y leaderboard).

Aceptada

Trazabilidad de resultados y gamificación medible.

ADR-08

Instrumentar observabilidad con métricas y paneles (Prometheus y Grafana).

Aceptada

Mejor diagnóstico operativo y apoyo a calidad de servicio.

ADR-09

Mantener varias estrategias de bot y mapear dificultad funcional a bots concretos.

Aceptada

Cumplimiento de requisito de múltiples estrategias seleccionables.

ADR-10

Separar la documentación de las APIs a un contenedor aparte

Aceptada

Mejorar el rendimiento de las APIs liberándolas de la carga de servir las documentaciones.

9.3. ADR-00. Base inicial docente y evolución del equipo

Contexto

El proyecto parte de una base inicial del laboratorio (plantilla y estructura funcional mínima), con contribuciones tempranas del profesorado, y se amplía después con trabajo del equipo.

Decisión

Conservar la base inicial y evolucionarla incrementalmente, priorizando continuidad técnica y trazabilidad de cambios.

Consecuencias

Positivas: menor tiempo de arranque y estructura común de trabajo. Costes: necesidad de revisar supuestos iniciales y endurecer diseño en seguridad, pruebas y contratos.

9.4. ADR-01. YEN como contrato de dominio común

Contexto

Los requisitos exigen interoperabilidad por JSON y notación YEN entre módulos.

Decisión

YEN se establece como representación canónica del estado de partida para intercambio entre frontend y motor.

Consecuencias

Evita conversiones ambiguas entre capas. Permite validación centralizada y pruebas de serialización/deserialización. Facilita integración de clientes externos.

9.5. ADR-02. Arquitectura por componentes desacoplados

Contexto

Se requiere al menos una aplicación web en TypeScript y un módulo en Rust para lógica de juego.

Decisión

Separar el sistema en tres componentes principales:

Webapp: experiencia de usuario y flujo de interacción. Users: autenticación, perfil, historial, ranking y persistencia. Gamey: validación de jugadas, estado de partida y bots. .Consecuencias

Escalado y despliegue por componente. Mejor encapsulamiento de responsabilidades. Incremento de complejidad de integración (compensado con contratos y tests).

9.6. ADR-03. Lógica de juego y bots centralizada en Rust

Contexto

Las reglas del juego Y y la validación de jugadas son el núcleo crítico de consistencia.

Decisión

Delegar en Gamey la validación de jugada, control de fin de partida y cálculo de movimiento de bots; la web no implementa reglas de victoria como fuente de verdad.

Consecuencias

Integridad funcional más robusta. Menor riesgo de divergencia entre cliente y servidor. Necesidad de conversión clara entre coordenadas de UI y coordenadas baricéntricas.

9.7. ADR-04. API de juego versionada para integraciones

Contexto

Debe existir API utilizable por bots y consumidores externos.

Decisión

Versionar los endpoints del motor de juego (prefijo v1) y soportar petición de movimiento con bot explícito o por defecto, manteniendo compatibilidad evolutiva.

Consecuencias

Contrato más estable para terceros. Cambios futuros pueden introducirse sin romper consumidores existentes. Requiere disciplina de versionado en iteraciones posteriores.

9.8. ADR-05. Seguridad con JWT y ciclo de refresh

Contexto

Las operaciones sobre datos de usuario y registro de partidas requieren control de acceso.

Decisión

Aplicar autenticación basada en token de acceso y token de refresco, con rotación/revocación de refresh en el servicio de autenticación.

Consecuencias

Mejora del control de sesión y del riesgo de reutilización de credenciales. La persistencia de sesión de refresh actual está orientada a entorno de desarrollo; para escalado horizontal completo se requiere backend compartido de sesiones.

9.9. ADR-06. Persistencia dual según entorno (local vs despliegue)

Contexto

El equipo necesita rapidez de desarrollo local y despliegue real en Azure.

Decisión

Mantener dos modos de operación de base de datos, con mismo modelo lógico:

Desarrollo local: servicio MySQL en contenedor para pruebas y trabajo diario. Despliegue: conexión a base de datos de Azure mediante variables de entorno. .Consecuencias

Reproducibilidad local con Docker Compose. Menor fricción para despliegue real sin depender del contenedor de base de datos local. La configuración por entorno se vuelve decisión crítica de operación.

9.10. ADR-07. Modelo de puntuación y ranking

Contexto

Los requisitos funcionales incluyen histórico y estadísticas de participación.

Decisión

Usar una puntuación determinista por partida, calculada a partir de tamaño de tablero y número de turnos, y persistir resultados para leaderboard y perfil.

Formulación aplicada

score = boardSize * 10 + max(0, 50 - turnNumber)

Consecuencias

Métrica simple, trazable y explicable para el usuario. Permite ranking global, perfil y vistas centradas en usuario. Facilita pruebas de regresión sobre reglas de puntuación.

9.11. ADR-08. Observabilidad incorporada desde la arquitectura

Contexto

Los criterios de valoración incluyen disponibilidad y monitorización.

Decisión

Instrumentar el backend y desplegar stack de monitorización con Prometheus y Grafana en entorno contenedorizado.

Consecuencias

Visibilidad de salud y rendimiento de servicios. Detección temprana de problemas de latencia y errores. Coste operativo adicional asumido por el valor en diagnóstico.

9.12. ADR-09. Estrategias múltiples de bot y dificultad seleccionable

Contexto

Se exige más de una estrategia de juego contra máquina y selección de dificultad.

Decisión

Mantener varias estrategias en Gamey (aleatoria, media y difícil) y mapear dificultad de UX a identificadores de bot concretos.

Consecuencias

Cumplimiento directo del requisito funcional de estrategias. Extensible a nuevos bots sin rediseñar la UI. Necesidad de mantener coherencia entre nomenclatura de dificultad y bot real disponible.

9.13. ADR-10. Separar documentación de APIs a un contenedor aparte

Contexto

Las APIs actuales manejan tanto el tráfico de producción como las consultas a la documentación interactiva (Swagger UI/OpenAPI). Esta carga adicional impacta negativamente en el rendimiento de las APIs, especialmente cuando desarrolladores y usuarios realizan pruebas frecuentes desde la interfaz de documentación.

Decisión

Desplegar la documentación de las APIs (Swagger UI) en un contenedor separado e independiente, sirviendo los archivos de especificación OpenAPI desde este nuevo contenedor.

Consecuencias

Mejora de rendimiento: Las APIs ya no procesan peticiones de documentación ni ejecuciones de prueba desde Swagger UI, liberando recursos para peticiones de producción

Escalabilidad independiente: La documentación puede escalarse según demanda (ej. durante onboarding de nuevos desarrolladores) sin afectar las APIs de producción

Despliegues desacoplados: Actualizaciones a la documentación no requieren redesplegar las APIs, y viceversa.

Mayor modularidad: Facilita la gestión y evolución independiente de la documentación técnica

Requiere gestión de un contenedor adicional en la infraestructura.

10. Requisitos de calidad

Content

This section contains all quality requirements as quality tree with scenarios. The most important ones have already been described in section 1.2. (quality goals)

Here you can also capture quality requirements with lesser priority, which will not create high risks when they are not fully achieved.

Motivation

Since quality requirements will have a lot of influence on architectural decisions you should know for every stakeholder what is really important to them, concrete and measurable.

Further Information

See Quality Requirements in the arc42 documentation.

10.1. Árbol de calidad

Content

The quality tree (as defined in ATAM – Architecture Tradeoff Analysis Method) with quality/evaluation scenarios as leafs.

Motivation

The tree structure with priorities provides an overview for a sometimes large number of quality requirements.

Form

The quality tree is a high-level overview of the quality goals and requirements:

  • tree-like refinement of the term "quality". Use "quality" or "usefulness" as a root

  • a mind map with quality categories as main branches

In any case the tree should include links to the scenarios of the following section.

Árbol de calidad

10.2. Escenarios de calidad

Contents

Concretization of (sometimes vague or implicit) quality requirements using (quality) scenarios.

These scenarios describe what should happen when a stimulus arrives at the system.

For architects, two kinds of scenarios are important:

  • Usage scenarios (also called application scenarios or use case scenarios) describe the system’s runtime reaction to a certain stimulus. This also includes scenarios that describe the system’s efficiency or performance. Example: The system reacts to a user’s request within one second.

  • Change scenarios describe a modification of the system or of its immediate environment. Example: Additional functionality is implemented or requirements for a quality attribute change.

Motivation

Scenarios make quality requirements concrete and allow to more easily measure or decide whether they are fulfilled.

Especially when you want to assess your architecture using methods like ATAM you need to describe your quality goals (from section 1.2) more precisely down to a level of scenarios that can be discussed and evaluated.

Form

Tabular or free form text.

10.2.1. Escenarios de rendimiento

ID Escenario

QP01

Cuando 100 usuarios inician sesión y acceden simultáneamente al sistema, este mantiene tiempos de respuesta aceptables en la navegación principal.

QP02

Cuando 100 usuarios juegan partidas al mismo tiempo, el tablero se actualiza sin bloqueos visibles para el usuario.

QP03

Cuando un jugador realiza un movimiento, la interfaz refleja el cambio en el tablero en un tiempo coherente.

QP04

Cuando la API recibe peticiones concurrentes de bots, el servicio responde sin degradar excesivamente el sistema.

QP05

Cuando se consulta el historial de partidas de un usuario con muchas partidas almacenadas, la lista se carga en un tiempo razonable.

QP06

Cuando se solicitan estadísticas básicas, el sistema las calcula y muestra de manera rápida.

QP07

Cuando el motor del juego recibe una posición YEN válida, la validación de victoria se completa en un tiempo predecible.

QP08

Cuando la API devuelve el estado de una partida en formato YEN, la serialización JSON no introduce demasiada latencia.

10.2.2. Escenarios de seguridad

ID Escenario

QS01

Cuando un usuario se registra, la contraseña se almacena con un hash seguro.

QS02

Cuando un usuario mantiene una sesión activa, el sistema protege la sesión frente a accesos no autorizados.

QS03

Cuando un usuario cierra sesión, la sesión queda invalidada y no puede reutilizarse.

QS04

Cuando un bot llama a la API, debe autenticarse antes de crear o modificar partidas.

10.2.3. Escenarios de mantenibilidad

ID Escenario

QM01

Cuando se añade una nueva funcionalidad, la modificación se cubre con pruebas unitarias.

QM02

Cuando un desarrollador incorpora una nueva funcionalidad en cualquier módulo del sistema, el código mantiene una cobertura de código mínima del 70%.

QM03

Cuando un nuevo desarrollador revisa el código, puede entender la estructura principal a partir de la documentación del sistema.

10.2.4. Escenarios de usabilidad

ID Escenario

QU01

Cuando el tablero cambia tras un movimiento, el usuario entiende visualmente qué pieza se ha movido.

QU02

Cuando termina una partida, el usuario identifica de forma inmediata si ha ganado o perdido.

QU03

Cuando el usuario consulta su historial, puede localizar partidas anteriores sin esfuerzo excesivo.

QU04

Cuando el usuario usa la plataforma por primera vez, entiende cómo registrarse, iniciar sesión y empezar una partida.

10.2.5. Escenarios de interoperabilidad

ID Escenario

QI01

Cuando la aplicación web envía una partida al módulo Rust, el intercambio se realiza exclusivamente en JSON con notación YEN.

QI02

Cuando la API devuelve el estado de una partida, el formato es siempre JSON válido.

QI03

Cuando un bot crea una partida, recibe una respuesta compatible con el contrato de la API sin necesidad de adaptaciones manuales.

QI04

Cuando un bot envía un movimiento, la API interpreta correctamente la estructura JSON acordada.

QI05

Cuando el módulo Rust recibe una notación YEN inválida, devuelve un error compatible con el contrato definido.

10.2.6. Escenarios de funcionalidad crítica

ID Escenario

QF01

Cuando un jugador realiza un movimiento legal, el sistema actualiza el estado de la partida correctamente.

QF02

Cuando un jugador realiza un movimiento ilegal, el sistema lo rechaza sin corromper la partida.

QF03

Cuando una partida termina, el sistema registra el resultado en el historial del usuario correcto.

QF04

Cuando el módulo Rust analiza una posición YEN con victoria, identifica correctamente al ganador.

QF05

Cuando el módulo Rust analiza una posición YEN sin ganador, informa correctamente de continuidad.

10.2.7. Escenarios de cambio

ID Escenario

QC01

Cuando se introduce una nueva implementación de un bot, no es necesario reescribir la lógica central.

QC02

Si se sustituyera la base de datos empleada, el front-end no se vería afectado.

QC03

Si se sustituyera la interfaz web por otra tecnología, el contrato con la API de bots sigue estable.

11. Riesgos y Deuda Técnica

Contents

A list of identified technical risks or technical debts, ordered by priority

Motivation

“Risk management is project management for grown-ups” (Tim Lister, Atlantic Systems Guild.)

This should be your motto for systematic detection and evaluation of risks and technical debts in the architecture, which will be needed by management stakeholders (e.g. project managers, product owners) as part of the overall risk analysis and measurement planning.

Form

List of risks and/or technical debts, probably including suggested measures to minimize, mitigate or avoid risks or reduce technical debts.

Further Information

See Risks and Technical Debt in the arc42 documentation.

11.1. Enfoque

Este apartado identifica los principales riesgos técnicos y deudas técnicas del estado actual del sistema, ordenados por prioridad. Se incluyen medidas de mitigación para facilitar su seguimiento.

Criterio de priorización:

  • Alta: impacto elevado en seguridad, disponibilidad o corrección funcional.

  • Media: impacto relevante, pero con alternativas temporales.

  • Baja: impacto acotado o de mejora progresiva.

11.2. Riesgos Técnicos (priorizados)

ID Prioridad Riesgo Evidencia en el repositorio Mitigación propuesta

R-01

Alta

Sesiones de refresh en memoria del proceso: al reiniciar el servicio se pierde el estado de sesiones y en despliegue con varias instancias no hay sincronización de revocaciones.

users/auth/sessionStore.js usa Map en memoria. En users/users-service.js se indica explícitamente que para producción debe persistirse en DB.

Persistir sesiones de refresh en almacenamiento compartido (MySQL o Redis), con hash de token, revocación y trazabilidad de cadena de rotación.

R-02

Alta

Respuesta potencialmente inconsistente al finalizar partida: el endpoint devuelve gameId, pero en el servicio no se asigna valor final antes del retorno.

En users/services/gameService.js, recordFinishedMatch declara let gameId; y retorna gameId sin asignarlo tras insertFinishedGame.

Corregir retorno para devolver el id real de partida insertada y añadir prueba de integración que valide gameId no nulo.

R-03

Alta

Superficie de ataque ampliada por CORS abierto: aceptación global de orígenes y cabeceras.

users/users-service.js permite Access-Control-Allow-Origin: *; en gamey/src/bot_server/mod.rs y gamey/src/game_server/mod.rs se usa allow_origin(Any).

Restringir CORS por entorno (lista blanca de dominios), limitar métodos y cabeceras, y documentar política de acceso por servicio.

R-04

Media

Riesgo de configuración errónea en frontend para despliegue: URL de Gamey hardcodeada a localhost.

webapp/src/services/gamePlayApi.js tiene const GAMEY_BASE_URL = "http://localhost:4000" y la opción por variable de entorno está comentada.

Reactivar configuración por VITE_GAMEY_URL, definir valores por entorno y añadir validación en build/release.

R-05

Media

Fragmentación de contrato API: la especificación OpenAPI documenta users, pero no centraliza completamente los endpoints de juego/bots de gamey.

users/openapi.yaml describe autenticación, historial y ranking; endpoints de gamey (/game/play/, /{api_version}/play/{bot_id}, /{api_version}/choose/{bot_id}) se implementan en Rust fuera de ese contrato.

Publicar contrato unificado o federado (Users + Gamey), versionado y validado en CI para evitar deriva entre implementación y documentación.

R-06

Media

Ausencia de validación de carga extremo a extremo: puede ocultar cuellos de botella en picos de uso.

Hay unit/integration/e2e y benchmarks en Rust (gamey/benches), pero no se identifican suites de carga HTTP integrales para el sistema desplegado.

Incorporar pruebas de carga (p. ej., k6) para /auth/*, /finished-match, /leaderboard y endpoints de bot, con umbrales de latencia y error.

R-07

Media

Conexión DB única y reconexión limitada: una única conexión puede degradar robustez en escenarios concurrentes o fallos intermedios.

users/db.js usa mysql.createConnection con cache global y reintentos solo al inicio.

Migrar a pool (createPool) con políticas de reconexión y timeouts; añadir métricas de saturación y errores de DB.

R-08

Media

Dualidad de topología de BD local vs despliegue: riesgo de desviación de configuración y operaciones entre entornos.

Local con docker-compose y servicio mysql; despliegue con DB externa en Azure por variables (README.md, users/.env.example, users/scripts/init-db.sh).

Definir checklist de paridad entre entornos (variables, esquema, backup/restore, red), automatizar migraciones y verificación post-despliegue.

11.3. Deuda Técnica (priorizada)

ID Prioridad Deuda técnica Impacto Plan de reducción

D-01

Alta

Persistencia de refresh token no preparada para multi-instancia.

Puede invalidar estrategia de seguridad en escalado horizontal.

Implementar almacenamiento persistente compartido y limpiar sesiones expiradas por tarea programada.

D-02

Alta

Bug funcional pendiente en retorno de gameId (recordFinishedMatch).

Inconsistencias en API y en trazabilidad de partidas guardadas.

Arreglar retorno, añadir pruebas en users/tests y control en contrato OpenAPI.

D-03

Media

Configuración de endpoint de Gamey acoplada a localhost en frontend.

Riesgo de errores en entornos de staging/producción y mayor coste de despliegue.

Parametrización por variables de entorno y validación en pipeline de release.

D-04

Media

Contrato API no consolidado entre Users y Gamey.

Mayor probabilidad de divergencia entre documentación y endpoints reales.

Mantener especificaciones sincronizadas y validación automática de contrato en CI.

D-05

Media

Ausencia de pruebas de carga de sistema completo.

Riesgo no cuantificado de latencia y degradación bajo concurrencia.

Definir escenarios de carga mínimos por requisito y ejecutarlos en cada release candidata.

D-06

Media

Política CORS permisiva en varios servicios.

Exposición innecesaria de endpoints en entornos públicos.

Endurecer CORS por entorno, auditar cabeceras y probar comportamiento con tests de seguridad básicos.

D-07

Baja

Uso de valores por defecto de secretos para desarrollo (dev-access-secret-change-me, dev-refresh-secret-change-me).

Riesgo bajo en local, pero crítico si se reutiliza en despliegue real por error.

Forzar secretos obligatorios en producción (fallo de arranque si faltan) y documentar política de rotación.

12. Informe de Pruebas

12.1. Tests Unitarios

Los tests unitarios verifican el comportamiento correcto de cada componente, helper y módulo de forma aislada, proporcionando seguridad, consistencia y confianza durante el desarrollo.

12.1.1. Webapp (Vitest + React Testing Library)

La webapp cubre la interfaz de usuario, los formularios de autenticación, el flujo de juego, la lógica de estado y las llamadas a servicios.

Archivo de test Qué verifica Casos

App.test.jsx

Renderizado de las acciones globales, visibilidad de botones según sesión, apertura/cierre de ayuda y logout.

4

AuthPage.test.jsx

Validación de login y registro, mensajes de error en pantalla, transiciones de flujo y comportamiento tras credenciales inválidas.

5

GameBoard.test.jsx

Gestión de clics en el tablero, validaciones de movimiento, modos 1vs1 y 1vsbot, errores de backend y visualización de VictoryMenu.

54

LanguageSelector.test.jsx

Cambio de idioma mediante el selector y reflejo de la selección en la interfaz.

1

authApi.test.js

Requests a /auth/*: login, registro, refresh y logout; serialización de peticiones, headers y errores del servidor.

28

boardStore.test.js

Estado de juego: inicialización de tablero, clamp de tamaño, avance de turnos, gestión de tiempo y snapshots de tablero.

56

gamePlayApi.test.js

Validación de peticiones de juego a backend, gestión de estado de partida y manejo de errores HTTP.

26

GlobalActionsBar.test.jsx

Barra superior de la aplicación: botones de logout, ayuda y cambios globales de estado.

5

Header.test.jsx

Representación del encabezado principal, rutas de navegación y visualización de usuario autenticado.

4

KonvaRenderer.test.jsx

Renderizado del tablero con Konva y marcado de celdas, animaciones y escalado visual.

9

leaderboardApi.test.js

Peticiones de ranking: parámetros de filtro, paginación y respuestas de leaderboard.

5

LeaderboardPage.test.jsx

Página de ranking: carga de datos, paginación, búsqueda de usuarios y ordenación.

26

PaginationControls.test.jsx

Controles de paginación: navegación entre páginas, botones prev/next y cambio de tamaño de página.

2

PlayerBadge.test.jsx

Visualización de la información del jugador, iconos de estado y notificaciones de ganador.

5

sessionStore.test.js

Gestión de sesión en el frontend: persistencia, expiración y restauración de credenciales.

3

StartGameForm.test.jsx

Formulario de inicio de partida: selección de modo, dificultad, número de jugadores y validación de entradas.

7

useDebouncedSearch.test.js

Hook de búsqueda con debounce: llamadas diferidas, cancelación y resultados esperados.

1

UserProfilePage.test.jsx

Visualización y edición del perfil de usuario, datos de estadísticas y pestañas de historial.

62

UserSearchBar.test.jsx

Búsqueda de usuarios en el frontend: sugerencias, filtrado y debounce.

25

usersScoreApi.test.js

Peticiones de puntuaciones de usuario: lista de puntuación, filtrado por usuario y errores de backend.

6

VictoryMenu.test.jsx

Menú de victoria: opciones de reinicio, compartir resultado y estadísticas finales.

5

yenParser.test.js

Parser de notación: conversión de movimientos y validación de entrada de tablero.

27

apiErrorHelper.test.js

Gestión de errores en llamadas a API: manejo de respuestas de error y mensajes de error.

3

12.1.2. Users Service (Vitest + Supertest)

El servicio users tiene 23 archivos de test en users/tests, probando la lógica de negocio, los endpoints de la API, la persistencia y las validaciones de dominio.

Archivo de test Qué verifica Casos

auth_tokens.test.js

Rotación y revocación de refresh tokens, refresh con token inválido y permisos de acceso a endpoints protegidos.

4

api_register.test.js

Registro de usuario: datos obligatorios, contraseñas no coincidentes, email duplicado y errores esperados.

4

api_login.test.js

Login: campos obligatorios, usuario inexistente, contraseña incorrecta y validación de tipos.

4

recordFinishedMatch.test.js

Persistencia de partidas 1vs1 y 1vsbot, validaciones de payload y rollback en errores de base de datos.

6

leaderboardService.test.js

Paginación, sugerencias de usuario, ranking y ejecución de historial con datos simulados.

6

userProfileEndpoints.test.js

Endpoints de perfil: obtención de datos públicos, historial paginado y leaderboard centrado.

3

gameService_userVsUser.test.js

Partida usuario vs usuario: gestión de estados, turnos y finalización.

4

userService.test.js

Lógica de usuario: autenticación, autorización y validaciones del dominio.

6

api_auth_endpoints.test.js

Autenticación por token: acceso a endpoints protegidos, permisos y expiración.

6

api_createuser.test.js

Creación de usuario: validación de payload y respuesta de la API.

5

api_finishedmatch.test.js

Registro de partida finalizada: cálculo de puntuaciones y actualización de histórico.

12

api_leaderboard.test.js

Obtención de ranking desde API: filtros, paginación y formato de respuesta.

8

createUser.test.js

Lógica de creación de usuario, hashing de contraseña y reglas de unicidad.

3

db.test.js

Conexión y manejo de errores de base de datos en el entorno de tests.

2

finishGame.test.js

Finalización de partidas: cálculo de resultado, persistencia y notificaciones.

4

gameDb.test.js

Operaciones CRUD en el repositorio de partidas.

14

gameRepo.test.js

Integración de repositorios: acceso y combinación de datos de usuarios y partidas.

19

gameService_botVsBot.test.js

Partida bot vs bot: lógica de juego automatizada y turnos.

2

gameService_userVsBot.test.js

Partida usuario vs bot: lógica de movimiento, dificultad y respuesta del bot.

2

rankingPaginationLegacyData.test.js

Compatibilidad de paginación con datos antiguos y estructura de respuesta.

2

repositoryWrappers.test.js

Encapsulación de acceso a repositorios para testeo y aislamientos de datos.

2

scoreService.test.js

Cálculo de puntuaciones y métricas de jugador.

3

userDb.test.js

Operaciones de usuario en la base de datos: creación, consulta y actualización.

8

Los tests de users ejercitan la lógica de los servicios y la capa de datos con mocks, manteniendo cada caso aislado sin depender de una base de datos real.

12.1.3. GameY (Rust — cargo test)

El motor Rust se prueba con cargo test, combinando tests de integración en gamey/tests y tests unitarios inline en los módulos de código fuente. Además cabe destacar que cada módulo de la lógica incluye en la parte inferior unas pruebas unitarias que comprueban el funcionamiento del módulo.

Archivo de test Qué verifica Casos

gamey/tests/core_tests.rs

Reglas de juego, tablero, alternancia de turnos y condiciones de victoria.

43

gamey/tests/bot_server_tests.rs

Para probar la correcta interación con los bots mediante peticiones HTTP.

14

gamey/tests/cli_tests.rs

Línea de comandos: parseo de argumentos, modos de juego y salida de ayuda.

54

12.2. Tests End-to-End (E2E)

Los tests end-to-end verifican que los flujos principales funcionan correctamente desde el navegador con la aplicación completa levantada. Estas se ejecutan sobre 3 navegadores distintos de forma concurrente: chromium, firefox y webkit. Todo esto con el fin de probar del sistema al completo en diferentes condiciones para garantizar el correcto funcionamiento del mismo en la medida de lo posible.

La suite E2E de la webapp reside en webapp/test/e2e/features y webapp/test/e2e/steps, y actualmente cubre los siguientes escenarios:

  1. Registro exitoso — register.feature valida el formulario de registro y comprueba el mensaje de confirmación tras enviar datos válidos.

  2. Login exitoso — auth.feature valida el flujo de autenticación y la navegación a la página principal tras credenciales correctas.

  3. Partida completa contra jugador local — game.feature comprueba que el usuario puede iniciar y finalizar una partida contra otro jugador local y ver el menú de victoria.

  4. Partida completa contra bot Easy/Medium/Hard — game.feature valida partidas completas contra los bots Easy, Medium y Hard, comprobando la finalización correcta del flujo y la visualización del resultado.

12.3. Tests de Carga

Los tests de carga miden el rendimiento del sistema ante una entrada de muchos usuarios al mismo tiempo, permitiendo anticipar problemas de rendimiento antes de que afecten a usuarios reales. En nuestro caso, dado que el sistema no deja de ser un producto con fines didacticos, las pruebas no contemplan un número de usuarios muy elevado en comparación con los sistemas existentes en la web.

Para la realización de estas pruebas se ha utilizado Gatling en su versión "gatling-charts-highcharts-bundle-3.15.0" (Java + Maven). Para realizar correctamente las pruebas, hemos usado : las instrucciones ofrecidas en el archivo .pdf correspondiente a la sesión 9 de prácticas, la documentación oficial de Gatling y el repositorio github en inglés ofrecido por los profesores para explicar el funcionamiento de las mismas.

12.3.1. Escenario de prueba

El escenario simula el flujo completo de un usuario jugando una partida:

  1. Registro del usuario — creación de una cuenta con su respectivo nombre, correo y contraseña.

  2. Login — autenticación del mismo y obtención del token de acceso.

  3. Comienzo de una partida - se inicia una partida contra el jugador 111 de manera local.

  4. Movimientos - se selecciona una sucesión de celdas (los movimientos están predefinidos).

  5. Victoria - se comprueba que, en efecto, se ha verificado la autenticidad del token y el usuario ha ganado la partida.

  6. Consulta de estadísticas - se accede al apartado de estádisticas e historial del jugador.

El código correspondiente al escenario se puede consultar en el archivo archivo webapp/test/load/MyGatlingSimulation.java. También se puede consultar el cuerpo de cada una de las peticiones .json realizadas durante la prueba en el directorio webapp/test/load/requests/.

12.3.2. Configuración de carga

Para ejecutar las pruebas de carga, se ha creado un archivo .csv con los datos correspondientes a 100 usuarios ficticios (archivo webapp/test/load/usuarios.csv).

De esta manera, se lanza cada uno de los usuarios durante un periodo de 100 segundos, con un retraso de 1 segundos entre cada usuario (rampUsers(15).during(30)).

12.3.3. Resultados

Métrica Valor resultante

Peticiones totales

3500 peticiones

Peticiones OK

3500 (100%)

Porcentaje de error

0%

Latencia mínima

14ms

Latencia media

30ms

Latencia máxima

208ms

Percentil 50 (p50)

22ms

Percentil 75 (p75)

36ms

Percentil 95 (p95)

95ms

Percentil 99 (p99)

105ms

Throughput medio

25,36 req/s

Duración total

164s

A continuación se muestran un conjunto de capturas para corroborar los datos obtenidas en las pruebas de carga realizadas. En cualquier caso, si se desea consultar los resultados obtenidos, se puede consultar el directorio webapp/test/load/results/.

Rangos de tiempos de respuesta
Número de usuarios lanzados por unidad de tiempo
Número de usuarios concurrentes
Distribución del tiempo de respuesta
Percentiles del tiempo de respuesta
Número de peticiones por segundo
Número de respuestas por segundo

13. Glosario

Contents

The most important domain and technical terms that your stakeholders use when discussing the system.

You can also see the glossary as source for translations if you work in multi-language teams.

Motivation

You should clearly define your terms, so that all stakeholders

  • have an identical understanding of these terms

  • do not use synonyms and homonyms

Form

A table with columns <Term> and <Definition>.

Potentially more columns in case you need translations.

Further Information

See Glossary in the arc42 documentation.

Término Definición

YOVI

Nombre del sistema desarrollado para jugar al juego Y mediante una aplicación web y servicios backend.

Juego Y

Juego abstracto de conexión sobre tablero triangular. Gana quien conecta los tres lados del tablero con fichas de su color.

YEN (Y-game Exchange Notation)

Notación JSON usada para representar una partida en un instante concreto. Es el formato canónico de intercambio entre servicios.

YGN

Notación relacionada con el dominio del juego Y, incluida en el motor como parte del soporte de formatos.

Layout

Campo de YEN que codifica la disposición de fichas por filas del tablero, usando símbolos de jugador y celdas vacías.

Turn

Campo de YEN que indica a qué jugador le corresponde realizar el siguiente movimiento.

Coordenadas baricéntricas

Sistema de coordenadas de tres valores (x,y,z) que expresa la distancia de una celda a cada lado del tablero triangular.

Coordenadas axiales de UI (q,r)

Coordenadas usadas en el frontend para identificar celdas del tablero. Se transforman a coordenadas baricéntricas en el backend/motor.

Webapp

Aplicación cliente desarrollada con React/Vite que gestiona interacción con el usuario, visualización del tablero y llamadas a APIs.

Users Service

Servicio Node/Express responsable de usuarios, autenticación, persistencia de partidas finalizadas, historial y leaderboard.

Gamey

Módulo Rust que implementa reglas del juego, validación de jugadas, detección de victoria y APIs de bots.

API versionada (v1)

Versión de API usada en endpoints del motor de juego/bots para permitir evolución controlada del contrato.

Bot

Agente automático que calcula jugadas válidas a partir del estado de una partida.

Estrategia de bot

Algoritmo concreto usado por un bot para elegir la siguiente jugada.

random_bot

Bot de dificultad baja que selecciona movimientos válidos de forma aleatoria.

medium_bot

Bot de dificultad media con heurísticas intermedias.

hard_bot

Bot de mayor dificultad usado por defecto en la API play cuando no se especifica otro bot.

Dificultad (Facil, Media, Dificil)

Nivel seleccionado por el usuario en frontend, mapeado internamente a bots concretos (random_bot, medium_bot, hard_bot).

JWT (JSON Web Token)

Mecanismo de autenticación utilizado para proteger endpoints sensibles mediante tokens firmados.

Access Token

Token JWT de vida corta usado para autorizar peticiones autenticadas.

Refresh Token

Token JWT usado para renovar el access token sin relogin; su uso está sujeto a revocación/rotación de sesión.

Session Store

Componente que mantiene el estado de sesiones de refresh token. En el estado actual se implementa en memoria del proceso.

/finished-match

Endpoint del servicio Users para registrar partidas terminadas y calcular/persistir puntuación.

Score (Puntuación)

Valor numérico de rendimiento de partida. En el estado actual se calcula como boardSize * 10 + max(0, 50 - turnNumber).

Leaderboard

Clasificación global de usuarios ordenada por métricas de puntuación y actividad.

Historial de partidas

Conjunto de partidas previas de un usuario, incluyendo modos de juego, resultado y métricas asociadas.

OpenAPI

Especificación del contrato HTTP del servicio Users, publicada para facilitar integración y validación.

Swagger UI

Interfaz web para explorar y probar endpoints descritos en OpenAPI.

Docker Compose

Orquestación local de servicios (webapp, users, gamey, mysql y monitorización) para desarrollo y pruebas reproducibles.

MySQL local

Base de datos levantada en contenedor para desarrollo e integración en entorno local.

Base de datos en Azure

Base de datos usada en despliegue, configurada por variables de entorno y separada del contenedor MySQL local.

Volumen mysql_data

Volumen Docker que conserva datos de MySQL entre reinicios de contenedores en entorno local.

Prometheus

Sistema de recolección de métricas usado para observabilidad técnica de los servicios.

Grafana

Herramienta de visualización de métricas y paneles para monitorización operativa.

Pruebas unitarias

Pruebas de componentes/funciones aisladas en frontend, backend Node y motor Rust.

Pruebas de integración

Pruebas de interacción entre módulos o capas (por ejemplo, endpoint + servicio + repositorio).

Pruebas e2e

Pruebas extremo a extremo que validan flujos completos desde perspectiva de usuario.