Parte de Ecentia Ecentia

Esta sección reúne toda la documentación técnica y de gestión desarrollada para el Proyecto Final del Ciclo Formativo de Grado Superior en Desarrollo de Aplicaciones Multiplataforma (DAM), realizado para el instituto IES Francisco Rodríguez Marín.

Documento General

Introducción y Contexto

Espacio para la introducción y contexto del proyecto Nexus.

Contenido pendiente de redactar...

Análisis y Requisitos

Definición de los requisitos funcionales y no funcionales, así como el análisis del dominio.

Contenido pendiente de redactar...

Diseño

Arquitectura del sistema, diseño de la interfaz de usuario y diseño de la base de datos.

Contenido pendiente de redactar...

Implementación

Detalles sobre el desarrollo, tecnologías utilizadas y retos técnicos superados.

Contenido pendiente de redactar...

Pruebas y Evaluación

Metodología de pruebas, resultados obtenidos y evaluación del sistema.

Contenido pendiente de redactar...

Conclusiones y Posibles Mejoras

Resumen final del proyecto y líneas de trabajo futuras.

Contenido pendiente de redactar...

Bibliografía

Fuentes de información, libros, artículos y recursos web consultados.

Contenido pendiente de redactar...

Anexos

Documentación complementaria, manuales de usuario o capturas de pantalla adicionales.

Contenido pendiente de redactar...
Documentos Adicionales

Plan de Proyecto

Cronograma, gestión de recursos y fases del desarrollo.

1. Introducción y contexto

Nexus es una idea muy simple: hacer más fácil la vida a la gente que quiere ahorrar. Hoy en día, si buscas un buen precio, tienes que abrir mil apps distintas, comparar en webs, revisar descuentos y mirar si alguien vende lo mismo más barato de segunda mano. Es un lío.

Por eso hemos pensado en Nexus, una aplicación gratuita que reúne todo eso en un solo lugar. Aquí puedes encontrar tanto productos nuevos con ofertas y descuentos, como artículos de segunda mano entre particulares. Todo junto, claro y sin perder tiempo. Las empresas también podrán colgar promociones de sus productos y hacer promoción de ellos.

La idea es que ahorrar deje de ser un esfuerzo y se convierta en algo natural mediante nuestra aplicación. Que puedas encontrar lo que buscas sin complicaciones, con una experiencia sencilla y agradable. Al final, Nexus no quiere ser solo otra app más, sino ese compañero del día a día que te echa una mano para cuidar tu dinero y aprovechar mejor tu tiempo.

2. Alcance del proyecto

Vamos a centrarnos en lo que es verdaderamente esencial para asegurarnos de que la primera versión de Nexus sea sólida y fácil de usar. No queremos lanzar una aplicación que haga mil cosas a medias, sino que haga pocas cosas a la perfección.

También nos gustaría que estén disponibles en varios sistemas operativos, pero debemos empezar por una aplicación web y después mediante Ionic + Capacitor compilar las aplicaciones móviles para Android e iOS (las cuáles compartirán un backend unificado).

Esta primera versión es nuestra carta de presentación al mundo. Por eso, planteamos con mucho cuidado qué podrás hacer en la app desde el primer día y qué mejoras y funciones increíbles iremos añadiendo después, escuchando siempre lo que nos digan nuestros usuarios.

La idea es construir una base fuerte y luego levantar el resto del edificio sobre ella. Cuando busques algo, no tendrás que preocuparte por si es nuevo o usado; nuestro buscador unificado encuentra todo a la vez y te lo muestra de forma ordenada.

Por supuesto, podrás crear tu propio perfil, con tu foto y una pequeña descripción, para que otros usuarios vean tu valoración, ya que la confianza es la base.

Y si algo te interesa, podrás ponerte en contacto de inmediato con el vendedor a través de un chat privado dentro de la app, como cualquier otra red social.

3. Cronograma del proyecto

Fase Actividades Principales Duración / Fechas Responsable
Fase 1: Hacer el plano Poner las ideas en papel, realizando bocetos y diseños de la interfaz. Decisión de colores, botones, categorías y elementos visuales. Noviembre 2025 - Diciembre 2025 Los tres integrantes
Fase 2: Construir el proyecto Desarrollo técnico de la aplicación. Implementación del backend con Spring (Java) y PostgreSQL, y del frontend con Angular. Diciembre 2025 - Marzo 2026 Los tres integrantes
Fase 3: Pulir y abrillantar Control de calidad, búsqueda y corrección de errores (bugs). Pruebas beta con usuarios reales para obtener feedback antes del lanzamiento. Abril 2026 - Mayo 2026 Los tres integrantes

4. Recursos

Para que Nexus sea una realidad, no nos queremos centrar en el dinero, sino el talento y la dedicación de un pequeño pero increíblemente enfocado equipo de tres desarrolladores.

Funcionaremos como una unidad compacta y multifuncional, donde los tres seremos los artesanos digitales responsables de dar vida a cada aspecto del proyecto. Esta estructura nos obliga a ser extremadamente ágiles, creativos y colaborativos, ya que las responsabilidades de gestión, diseño de la experiencia de usuario, arquitectura técnica y programación recaerá sobre nosotros. Por supuesto, además del equipo, necesitaremos los recursos financieros para poder dedicar el 100% de nuestro tiempo y energía a Nexus.

Además de programar Nexus (el servidor y la base de datos), alguno de nosotros asumirá de forma natural un rol de coordinación, organizando las tareas semanales y asegurándose de que el equipo siempre tenga claro el siguiente paso para cumplir con el ajustado calendario. Como Desarrolladores y Diseñadores de Experiencia (UX), nos encargaremos de construir todo lo que el usuario ve y toca en la pantalla del móvil. Nuestra misión es doble: no sólo escribiremos el código para que la aplicación funcione en iPhone y Android, sino que también nos encargaremos del diseño y la usabilidad.

5. Organización y gestión

Como somos solo tres programadores, no seremos como una empresa enorme. Aquí no hay jefes estrictos, papeleo innecesario ni juntas que se resolverán con un correo. Confiamos mucho el uno en el otro, hablamos directo y cada quien se hace responsable. Seremos como un equipo especial: rápidos, coordinados y con la meta bien clara. Para mantener algo de orden en todo esto, usaremos una versión sencilla de Scrum, que le viene bien a equipos chicos que necesitan ser rápidos y reaccionar ante cambios.

Cada dos semanas haremos un Sprint. Al comenzar, revisaremos la lista de cosas que queremos para la app y elegiremos las tareas más importantes. En eso nos enfocaremos las siguientes dos semanas. Así, dividimos el proyecto grande en partes pequeñas, y vemos el progreso todo el tiempo. Cada dos semanas tendremos algo nuevo de la aplicación que funciona, que podemos ver y probar.

Lo bueno de trabajar así es que somos un equipo muy eficiente y nos adaptamos fácil. No gastamos tiempo en planes que nunca se cumplen. Podemos probar ideas rápido, y si algo falla o se nos ocurre algo mejor, cambiamos sin problemas. Esto ayuda a que cada quien se sienta dueño de una parte del proyecto y nos mantiene motivados porque festejamos pequeñas victorias cada dos semanas. Con solo 6 meses, esta forma de trabajar es clave para lograrlo.

6. Gestión de riesgos

Hay tres cosas que nos preocupan mucho. Primero, el tiempo: seis meses es poco y no hay margen de error. Segundo, la competencia: hay empresas muy grandes en este mercado. Y tercero, el problema de quién va primero: necesitamos vendedores para que haya compradores, y al revés. Conocer estos problemas es clave para solucionarlos, y tenemos un plan para cada uno.

Para defendernos de estos problemas, vamos a usar nuestras ventajas como equipo pequeño. Para el problema del tiempo, seremos ágiles y nos centraremos en lo importante. Para la competencia, no competiremos en tamaño, sino creando una experiencia increíble para el usuario. Y para empezar con pocos usuarios, comenzaremos poco a poco: nos centraremos en algunas ciudades y categorías para crear una comunidad activa antes de expandirnos por todo el país. Usaremos los riesgos para impulsar nuestra estrategia.

Riesgo Probabilidad Impacto Plan de Mitigación
No cumplir con el plazo de 6 meses Media-baja Crítico Centrar el desarrollo en las funcionalidades esenciales (MVP) y escalar progresivamente según disponibilidad.
Mercado fantasma (baja tracción inicial) Alta Alto Marketing local enfocado, pruebas internas intensivas y captación de usuarios en círculos cercanos (amigos/familia).
Invisibilidad frente a competidores Media-alta Medio Posicionamiento basado en la propuesta de valor única: una solución "todo en uno" para ofertas y segunda mano.
Estafas o ambiente tóxico Media Crítico Implementación de sistemas de valoración de perfiles y funciones robustas de reporte y moderación comunitaria.

7. Aseguramiento de la calidad

Nuestro plan de calidad tiene tres bases. Primero, cada uno es responsable de su trabajo. Cada persona probará lo que hace para asegurarse de que todo esté bien hecho. Segundo, trabajamos en equipo. Revisamos el trabajo de los demás antes de añadirlo al proyecto. Así, tenemos otra opinión y encontramos errores que podríamos haber pasado por alto. Tercero, probamos las apps en situaciones reales. Antes de lanzarlas, les damos una versión de prueba a amigos y familiares para que la usen y nos den su opinión sincera.

Puede que este plan parezca que nos hace ir más lento, pero en realidad nos ayuda a avanzar más rápido. Es más fácil arreglar un error al principio que cuando ya lo está usando un cliente. Si un usuario encuentra un error, puede ser un problema grave y perder la confianza en la app. Queremos que la gente sienta que Nexus es una app profesional, sólida y confiable desde el primer momento.

Plan de Aseguramiento de la Calidad

8. Plan de comunicación

Tipo de Comunicación Frecuencia Medio Participantes
Comunicación presencial 2 horas semanales Sesiones presenciales en el centro educativo Los tres integrantes
Sincronización online Frecuente / Diaria Canales de Discord y herramientas de mensajería Los tres integrantes
Reunión de seguimiento Mensual Videollamada vía Discord Los tres integrantes
Informes y boletines Mensual Email y publicación de novedades en plataforma web Los tres integrantes
Exposiciones técnicas Hitos del proyecto Presentaciones presenciales en clase Los tres integrantes

9. Plan de cierre

Lanzar la app en mayo de 2026 no es el final, solo el fin del primer paso y el comienzo de algo mejor. El plan para terminar el proyecto es pasar de crear a crecer y mantener. Es como cuando un hijo empieza a caminar solo, nosotros lo guiaremos.

Para cerrar bien, haremos una revisión final para revisar que todo esté como queríamos desde el inicio. Luego, ordenaremos y explicaremos todo nuestro trabajo. Esto es importante para que después podamos mejorar la app sin problemas.

Al final, tendremos una reunión en equipo para hablar de cómo nos sentimos. No hablaremos de código, sino de cómo trabajamos, qué salió bien, qué hicimos mal y qué aprendimos.

Conclusión

Para mayo de 2026, esperamos tener la primera versión de Nexus lista y funcionando bien. Esto preparará la aplicación para crecer y mejorar fácilmente en el futuro. Durante este tiempo, revisaremos todo con cuidado, documentamos bien el proceso y analizaremos qué funcionó y qué no para aprender juntos. Así, nos aseguraremos de que la app ayude a la gente a ahorrar de manera práctica y con buena calidad.

Estudio de Viabilidad

Análisis económico, técnico y operativo del proyecto.

1. Introducción y objetivos

Nexus es una solución integral diseñada tanto para entornos web como móviles, que nace de la convergencia entre los principales portales de ofertas comunitarias y los marketplaces de compraventa entre particulares. El proyecto ofrece una plataforma unificada donde los usuarios pueden centralizar el descubrimiento de promociones destacadas, la gestión de productos de segunda mano y el acceso a anuncios corporativos en un ecosistema único.

El objetivo primordial es consolidar un espacio digital interactivo, con una estética cuidada y moderna, que permita a los usuarios:

  • Localizar y filtrar productos tanto nuevos como usados con facilidad.
  • Gestionar y publicar anuncios propios de forma intuitiva.
  • Participar activamente en la comunidad mediante valoraciones y votos ("likes"), definiendo la relevancia de las ofertas.
  • Acceder a un sistema logístico integrado con pasarela de pagos segura y gestión de comisiones.

2. Alcance preliminar

El alcance de este proyecto intermodular se centra en el desarrollo de una aplicación funcional multiplataforma (inicialmente Android con proyección a iOS) que integre las siguientes capacidades principales:

  • Dashboard Dinámico: Pantalla de inicio con visualización de ofertas destacadas y categorización inteligente de productos.
  • Marketplace de Segunda Mano: Espacio dedicado para que los usuarios publiquen y gestionen sus propios artículos.
  • Ranking de Popularidad: Sección de contenidos destacados, impulsada por la interacción social y el volumen de valoraciones positivas.
  • Búsqueda Unificada: Motor de búsqueda global capaz de indexar simultáneamente artículos nuevos, ofertas externas y productos usados.
  • Gestión de Identidad: Sistema de perfiles de usuario, historial de actividad y centro de control de publicaciones.
  • Sistema de Gestión de Envíos: Módulo logístico experimental para la gestión de envíos bajo un modelo de comisión controlado por la plataforma.

Exclusiones del Proyecto

Para asegurar la viabilidad técnica en los plazos establecidos, se han definido las siguientes exclusiones:

  • Transacciones Monetarias Reales: Aunque el sistema integra la infraestructura de Stripe, su funcionamiento está limitado al entorno de pruebas (Test Mode). No se realizarán cargos ni transferencias reales.

4. Viabilidad económica

El modelo financiero de Nexus se basa en una estructura de costes optimizada para el lanzamiento de una plataforma tecnológica en fase inicial, con un enfoque claro en la escalabilidad y la eficiencia operativa.

Estimación de Costes Iniciales

  • Desarrollo y Diseño UI/UX: Se estima una inversión de entre 6.000 € y 8.000 € para cubrir las fases de prototipado, desarrollo del MVP (Minimum Viable Product) y auditoría de seguridad inicial.
  • Infraestructura y Servicios: El mantenimiento de servidores, bases de datos y almacenamiento de medios se presupuesta en aproximadamente 500 € anuales mediante servicios cloud de pago por uso.
  • Marketing y Captación: Una partida inicial de 1.000 € destinada a campañas en redes sociales y posicionamiento SEO para captar los primeros usuarios activos.

Fuentes de Financiación y Monetización

El proyecto se financiará inicialmente mediante fondos propios o aportaciones de microinversores. La sostenibilidad financiera a largo plazo se apoyará en las siguientes vías de ingreso:

  • Comisiones de Gestión: Aplicación de un margen sobre las transacciones realizadas a través del sistema de envíos y pagos seguros.
  • Publicidad Destacada (B2B): Venta de espacios publicitarios premium y visibilidad mejorada para empresas y vendedores profesionales.

Análisis Costo-Beneficio

La inversión inicial es moderada y está dimensionada para minimizar el riesgo financiero. Nexus presenta un alto potencial de retorno (ROI) gracias a un modelo de negocio donde los ingresos crecen proporcionalmente al volumen de la comunidad, manteniendo unos costes operativos fijos muy reducidos.

5. Viabilidad operativa

La operatividad de Nexus se ha diseñado para maximizar la satisfacción del usuario final y ofrecer herramientas de gestión robustas para administradores y partners comerciales.

Impacto en la Experiencia de Usuario

La plataforma ofrece una interfaz minimalista y moderna que reduce la fricción en el proceso de compraventa. La integración de incentivos sociales (votos Spark/Drip y destacados dinámicos) fomenta una participación comunitaria activa y orgánica.

Impacto en el Ecosistema Empresarial

Nexus se posiciona como un canal publicitario eficiente para empresas, permitiéndoles promocionar su stock mediante anuncios patrocinados y productos con visibilidad preferente en el buscador global y en la pantalla de inicio.

Procesos de Gestión Interna

Para garantizar el correcto funcionamiento del sistema, se dispone de un Panel de Administración centralizado que permite:

6. Viabilidad legal y normativa

Para garantizar un entorno seguro y de confianza, Nexus se desarrolla bajo el cumplimiento estricto del marco legal vigente en materia de comercio electrónico y protección de datos.

7. Riesgos iniciales

Como todo proyecto tecnológico, Nexus se enfrenta a una serie de desafíos críticos. A continuación, se detallan los riesgos identificados y las estrategias diseñadas para mitigar su impacto:

Riesgo Descripción Medida de Mitigación
Competencia consolidada Existencia de plataformas líderes especializadas en nichos específicos (ofertas o compraventa). Diferenciación mediante la integración de ambos servicios en una única UX y un sistema social de valoración único.
Baja adopción inicial Dificultad para atraer a la masa crítica de usuarios necesaria para que el sistema de votos sea efectivo. Implementación de campañas de lanzamiento dirigidas y programas de bonificación por registro y actividad.
Contenido fraudulento Riesgo de publicación de artículos falsos, duplicados o intentos de estafa entre particulares. Uso de filtros automáticos basados en IA para moderación preventiva y un sistema robusto de reportes comunitarios.
Sostenibilidad de costes Incremento imprevisto en los costes de mantenimiento de servidores y APIs de terceros. Estructura de escalado progresivo y optimización de recursos según el volumen real de tráfico y usuarios.

8. Conclusión y recomendación

Tras el análisis exhaustivo de los factores técnicos, operativos y financieros, se concluye que el proyecto Nexus es altamente viable y presenta una oportunidad estratégica sólida en el mercado actual de aplicaciones multiplataforma.

Su enfoque innovador, que logra converger con éxito el dinamismo de las ofertas virales comunitarias con la robustez de un marketplace de compraventa entre particulares, le otorga una ventaja competitiva diferencial. La estructura de costes contenida y la escalabilidad de su arquitectura tecnológica aseguran que el proyecto pueda crecer de forma sostenible.

Recomendación final: Se recomienda proceder con la fase de implementación del MVP, priorizando la consolidación de la comunidad de usuarios inicial y la optimización de los algoritmos de relevancia social, elementos críticos para asegurar el éxito y la tracción del ecosistema Nexus.

Requisitos del Sistema

Proyecto: Nexus  ·  Versión: 2.0 (Producción)  ·  Fuente: Análisis del código fuente real (backend + frontend)

Nexus es una plataforma web de comercio y comunidad que unifica tres grandes módulos en un único ecosistema digital:

① Marketplace de segunda mano — compraventa de productos y vehículos entre particulares con pagos seguros mediante escrow.

② Chollometro comunitario — publicación y votación de ofertas externas de tiendas online y físicas con sistema de puntuación Spark/Drip.

③ Sistema de publicidad para empresas — contratos de patrocinio (banners y productos destacados) gestionados y pagados con Stripe.

El sistema está compuesto por un backend Spring Boot 3 (Java 17) con API REST y WebSocket STOMP, y un frontend Angular 17+ con Standalone Components, Signals reactivos y lazy loading total. La base de datos es PostgreSQL, el almacenamiento de medios se externaliza a Cloudinary y los pagos a Stripe.

Actores del Sistema

El sistema define cuatro tipos de actores representados mediante una jerarquía de herencia con una entidad base común Actor:

Visitante

  • No registrado
  • Acceso de solo lectura al catálogo
  • Puede registrarse o iniciar sesión
  • Interacción limitada (no puede publicar ni comprar)

Usuario

  • Registro con email o redes sociales
  • Puede publicar productos, vehículos y ofertas
  • Compra y venta con pagos seguros
  • Chat en tiempo real, favoritos, valoraciones
  • Puede convertirse en Empresa

Empresa

  • Perfil empresarial con CIF y nombre comercial
  • Acceso a contratos publicitarios (banners, patrocinios)
  • Pago de contratos mediante Stripe Checkout
  • Publicación de contenido como empresa verificada

Administrador

  • Panel de gestión exclusivo (dominio separado)
  • Moderación de usuarios, contenido y reportes
  • Gestión de contratos y publicidad
  • Estadísticas, auditoría y configuración global
  • Niveles de acceso (1, 2 o 3)

Requisitos de Información

Actores y Perfiles

RI-01

Información Común a Todos los Actores

De todos los actores del sistema se almacenará:

  • Identificación: nombre de usuario (único), email (único), contraseña (hash bcrypt), nombre, apellidos, teléfono.
  • Avatar: URL del avatar actual, fuente del avatar (GOOGLE, INITIALS, CUSTOM), URL del avatar de Google, URL del avatar personalizado.
  • Estado de cuenta: cuentaVerificada, cuentaEliminada (soft-delete RGPD), baneado, motivoBan, suspendidoHasta, motivoSuspension.
  • OAuth: googleId para autenticación con Google OAuth.
  • Seguridad: twoFactorEnabled, twoFactorMethod (TOTP o EMAIL), twoFactorSecret (cifrado), jwtVersion (invalidación de sesiones).
  • Sesión: ultimoIp, ultimoDispositivo, ultimaUbicacion, ultimoLogin.
  • Stripe: stripeCustomerId para pagos guardados.
  • Onboarding: onboardingCompletado para el wizard de bienvenida.

RI-02

Información Adicional del Usuario (Particular)

Adicionalmente a RI-01, del actor de tipo Usuario se almacenará:

  • biografía, ubicación, tipoCuenta (PERSONAL), fechaRegistro.
  • Reputación: reputación (media 0.0–5.0), totalVentas, esVerificado.
  • Privacidad: cuentaPrivada, perfilPublico, mostrarTelefono, mostrarUbicacion, permitirMensajesDesconocidos.
  • Preferencias de notificación: notifNuevosMensajes, notifNuevaCompra, notifValoracion, notifOfertas, notifEnvios, notifNovedades.
  • Dirección de envío por defecto (embebida): nombre completo, dirección, ciudad, código postal, país, teléfono.
  • Términos: terminosAceptados, versionTerminosAceptados, fechaAceptacionTerminos, newsletterSuscrito.

RI-03

Información Adicional de la Empresa

Adicionalmente a RI-01, de la Empresa se almacenará:

  • CIF (único), nombreComercial, descripción, web, teléfono, logo (URL), verificada (por administrador).

RI-04

Información Adicional del Administrador

Adicionalmente a RI-01, del Administrador se almacenará:

  • nivelAcceso (entero: 1 básico, 2 moderador, 3 superadmin).

Catálogo, Comercio y Logística

RI-05

Productos de Segunda Mano

De cada producto publicado en el marketplace se almacenará:

  • título, descripción, precio (EUR), precioNegociable, tipoOferta (VENTA, DONACION, INTERCAMBIO, SUBASTA, ALQUILER).
  • estado (DISPONIBLE, RESERVADO, VENDIDO, PAUSADO, ELIMINADO, EXPIRADO), condición (NUEVO, COMO_NUEVO, MUY_BUEN_ESTADO, BUEN_ESTADO, ACEPTABLE, PARA_PIEZAS).
  • categoría (FK), vendedor (FK Actor), marca, modelo.
  • Envío: admiteEnvio, precioEnvio, peso (kg).
  • Ubicación: ubicación (texto), latitud, longitud.
  • Imágenes: imagenPrincipal (URL Cloudinary), galeriaImagenes (hasta 5 URLs).
  • Métricas: numeroVistas, numeroFavoritos.
  • Ciclo de vida: fechaPublicacion, fechaCaducidad (publicación + 180 días), ultimoAvisoCaducidadDias.
  • Moderación admin: pausadoHasta, motivoPausa, destacado, patrocinado.

RI-06

Vehículos

Los vehículos extienden los campos de producto con información técnica específica:

  • tipoVehiculo (COCHE, MOTO, FURGONETA, SCOOTER, OTRO), marca, modelo, año, kilómetros.
  • combustible (GASOLINA, DIESEL, HÍBRIDO, ELÉCTRICO, GLP, GNC), cambio (MANUAL, AUTOMÁTICO), potencia (CV), cilindrada (cc).
  • color, numeroPuertas, plazas, matrícula (parcialmente oculta en público).
  • itv (booleano), fechaITV, garantía (booleano), extras (lista de características adicionales).

RI-07

Ofertas (Chollometro)

De cada oferta/chollo publicado se almacenará:

  • título, descripción, precioOferta, precioOriginal, tienda, urlOferta.
  • categoría (FK), publicador (FK Actor), estado (ACTIVA, PAUSADA, AGOTADA), esActiva.
  • badge automático (NUEVA, CHOLLAZO, PORCENTAJE, GRATUITA, EXPIRA_HOY), codigoDescuento.
  • Votos: sparkCount (positivos), dripCount (negativos), sparkScore (diferencia).
  • Métricas: numeroVistas, numeroCompartidos, numeroComentarios.
  • Flash: esFlash, flashFin, limiteUnidades, fechaExpiracion.
  • Localización: esOnline, ciudadOferta, gastosEnvio.
  • destacada (admin), imagenPrincipal (URL).

RI-08

Compras y Transacciones

De cada transacción de compra se almacenará:

  • comprador (FK), vendedor (FK), producto (FK), estado (PENDIENTE, PAGADO, ENVIADO, ENTREGADO, EN_DISPUTA, REEMBOLSADA, CANCELADA, COMPLETADA).
  • Importes: precioFinal, precioEnvio, costoEnvio, comisionNexus.
  • Stripe: stripePaymentIntentId, stripeChargeId.
  • Entrega: metodoEntrega, tipoEnvio, transportista, dirección completa de entrega.
  • Fechas: fechaCompra, fechaPago, fechaEnvio, fechaEntrega, fechaCompletada.

RI-09

Envíos y Devoluciones

De cada envío se almacenará: código único SHIP-XXXXXXXX, código QR (base64), transportista, número de seguimiento, URL de tracking, fechaLimiteEnvio.

De cada devolución se almacenará: motivo (PRODUCTO_DEFECTUOSO, NO_CORRESPONDE, DAÑO_TRANSPORTE, CAMBIO_DE_OPINIÓN, TALLA_INCORRECTA, OTRO), descripción, fotos de evidencia (hasta 4), dirección de devolución, nota del vendedor, importe devuelto, estado (SOLICITADA, ACEPTADA, RECHAZADA, COMPLETADA).

Social y Comunicación

RI-10

Mensajes de Chat

De cada mensaje de chat se almacenará: remitente (FK), receptor (FK), producto asociado (FK, opcional), texto, URL de media (imagen/vídeo/audio), duración de audio, tipo de mensaje (TEXTO, IMAGEN, VIDEO, AUDIO, GIF, OFERTA_PRECIO, SISTEMA), fecha de envío, leído, recibido, precio propuesto (en caso de propuesta de precio), estado de la propuesta (PENDIENTE, ACEPTADA, RECHAZADA), roomId (identificador único de la conversación).

RI-11

Valoraciones

De cada valoración se almacenará: comprador (FK), vendedor (FK), compra (FK, único — una valoración por compra), puntuación (1–5 estrellas), comentario opcional, respuesta del vendedor, fecha de respuesta.

RI-12

Categorías

Las categorías forman un árbol jerárquico (padre–hijos). De cada categoría: nombre, slug (único), icono, color, orden (para posición en menú), activa, referencia al padre (FK opcional).

RI-13

Notificaciones

De cada notificación in-app se almacenará: destinatario (FK Actor), título, mensaje, tipo (NUEVA_COMPRA, MENSAJE, ALERTA, ADVERTENCIA, FAVORITO_PRODUCTO, CADUCIDAD_ANUNCIO, DEVOLUCION, ENVIO_PLAZO, etc.), URL de destino, estado (leída, destacada), fecha.

RI-14

Reportes

De cada denuncia se almacenará: denunciante (FK), tipo de elemento denunciado (USUARIO, PRODUCTO, OFERTA, VEHICULO, MENSAJE, COMENTARIO), motivo (SPAM, FRAUDE, CONTENIDO_INAPROPIADO, PRODUCTO_FALSO, ACOSO, PRECIO_INCORRECTO, DUPLICADO, OTRO), descripción, estado (PENDIENTE, RESUELTO, DESESTIMADO).

Negocio y Publicidad

RI-15

Contratos Publicitarios

De cada contrato se almacenará: empresa (FK), tipo (BANNER, PUBLICACION), estado (DRAFT, PROPUESTA_ADMIN, PENDIENTE_PAGO, ACTIVE, RECHAZADO, EXPIRED, CANCELLED), fechas de inicio y fin, monto, producto patrocinado asociado (FK, opcional), stripeSessionId.

RI-16

Cupones de Descuento

De cada cupón se almacenará: código (único, máx. 20 caracteres), tipo de descuento (PORCENTAJE, FIJO), valor, importe mínimo de compra, tope máximo de descuento, alcance (TODOS, USUARIO_ESPECIFICO, GRUPO), límite de uso total, límite de uso por usuario, fechas de vigencia, categorías aplicables.

RI-17

Newsletter y Consentimiento RGPD

De cada suscripción al newsletter se almacenará: email, estado (activa/inactiva), IP del consentimiento, fecha del consentimiento, versión de la política de privacidad aceptada, token de baja (único), fecha de baja. Permite acreditar el consentimiento explícito conforme al artículo 7 del RGPD.

Requisitos Funcionales

Los requisitos funcionales describen las capacidades concretas que el sistema debe ofrecer a cada tipo de actor.

1

Actor No Registrado (Visitante) Público

Un visitante sin cuenta podrá realizar las siguientes acciones sin necesidad de autenticación:

RF-01

Exploración del Catálogo de Productos

El visitante podrá consultar el listado completo de productos de segunda mano disponibles, con acceso al detalle de cada uno: imágenes, descripción, precio, condición, ubicación del vendedor e información pública del vendedor (reputación, total de ventas, valoraciones).

RF-02

Exploración del Catálogo de Vehículos

El visitante podrá consultar el catálogo de vehículos con su ficha técnica completa (marca, modelo, año, kilómetros, combustible, equipamiento, galería de imágenes).

RF-03

Exploración de Ofertas y Chollos

El visitante podrá ver las ofertas publicadas por la comunidad, incluyendo precio original, precio de oferta, porcentaje de descuento, tienda, badge de categoría y puntuaciones Spark/Drip. Podrá acceder también a las secciones especializadas: Ofertas Flash (con cuenta atrás), Viajes y Gratis.

RF-04

Búsqueda y Filtrado Avanzado

El visitante podrá realizar búsquedas globales que abarquen simultáneamente productos, vehículos y ofertas. Dispondrá de los siguientes filtros:

  • Texto libre con expansión de sinónimos (ej.: "ps5" encuentra "PlayStation 5").
  • Categoría, rango de precio (mínimo y máximo), condición del artículo.
  • Antigüedad de la publicación (hoy, últimos 3 días, última semana, último mes).
  • Disponibilidad de envío, ordenación (novedades, precio asc/desc).
  • Filtros específicos de vehículos: marca, modelo, año, kilómetros, combustible, cambio, potencia, color, puertas, plazas, ITV y garantía.
  • Filtro geográfico por ubicación (manual o GPS) con radio ajustable en kilómetros y mapa interactivo.

RF-05

Consulta de Perfiles Públicos

El visitante podrá ver el perfil público de cualquier usuario (si este no lo tiene privado), incluyendo sus publicaciones activas, valoraciones recibidas, estadísticas de vendedor y descripción.

RF-06

Consulta de Categorías

El visitante podrá navegar el árbol jerárquico de categorías para filtrar el contenido disponible.

RF-07

Suscripción al Newsletter

El visitante podrá suscribirse al newsletter proporcionando su email. El sistema implementará double opt-in: enviará un correo de confirmación y solo activará la suscripción tras la confirmación. El visitante podrá darse de baja en cualquier momento mediante un token único incluido en cada email.

RF-08

Iniciación de Chat de Soporte

El visitante podrá iniciar una sesión de chat de soporte con el asistente virtual (IA) sin necesidad de estar registrado.

2

Registro y Autenticación Público

RF-09

Registro por Correo Electrónico

El visitante podrá crear una cuenta proporcionando: nombre de usuario (único), email (único, validado en tiempo real), contraseña (con medidor de fortaleza: longitud, mayúsculas, números y caracteres especiales), nombre, apellidos, aceptación de términos y condiciones, y opción de suscripción al newsletter. El sistema validará la disponibilidad del email y del nombre de usuario de forma asíncrona antes de confirmar el registro.

RF-10

Verificación de Email

Tras el registro, el sistema enviará un código de 6 dígitos al correo del usuario. La cuenta deberá ser verificada antes de poder acceder a todas las funcionalidades.

RF-11

Registro e Inicio de Sesión con Google

El visitante podrá registrarse e iniciar sesión mediante Google OAuth (Google One Tap y botón clásico), importando automáticamente nombre, email y avatar del perfil de Google.

RF-12

Inicio de Sesión con Email y Contraseña

El usuario registrado podrá autenticarse con email o nombre de usuario y contraseña. El sistema incluirá protección ante ataques de fuerza bruta mediante reCAPTCHA y limitación de intentos (rate limiting con retroalimentación visual del tiempo de espera).

RF-13

Autenticación en Dos Factores (2FA)

El usuario podrá configurar un segundo factor de autenticación eligiendo entre:

  • TOTP: código de 6 dígitos generado por una app autenticadora (Google Authenticator, Authy). El sistema generará un código QR para el proceso de vinculación.
  • Email OTP: código de un solo uso enviado al correo del usuario en cada inicio de sesión.

RF-14

Recuperación de Contraseña

El usuario podrá solicitar el restablecimiento de su contraseña introduciendo su email. El sistema enviará un enlace único con token (válido 15 minutos) para establecer una nueva contraseña.

RF-15

Onboarding Inicial

Tras el primer registro o acceso OAuth, el sistema guiará al nuevo usuario por un asistente de configuración inicial con los pasos: aceptación de términos, configuración de seguridad (2FA opcional), selección del tipo de cuenta (Personal o Empresa) y, para usuarios de Google, selección del avatar (foto de Google, iniciales o imagen propia).

3

Gestión de Cuenta y Perfil Autenticado

RF-17

Edición del Perfil Personal

El usuario podrá actualizar su nombre, apellidos, biografía, ubicación (con buscador y detección automática por GPS), teléfono y avatar (subir imagen propia, usar iniciales generadas automáticamente o recuperar la foto de Google si se registró con OAuth).

RF-18

Configuración de Privacidad

El usuario podrá controlar la visibilidad de su ubicación y teléfono en el perfil público, así como si desea recibir mensajes de usuarios desconocidos.

RF-19

Configuración de Notificaciones

El usuario podrá activar o desactivar individualmente las notificaciones para: nuevos mensajes, nueva compra, valoraciones recibidas, alertas de ofertas, actualizaciones de envíos y novedades de la plataforma.

RF-20

Cambio de Contraseña

El usuario podrá cambiar su contraseña desde la configuración de seguridad, previa verificación de la contraseña actual.

RF-21

Gestión de Sesiones Activas

El usuario podrá ver las sesiones activas registradas en su cuenta (dispositivo, IP, fecha) y cerrar todas las sesiones remotas simultáneamente, lo que invalidará todos los tokens JWT en circulación.

RF-22

Conversión de Cuenta Personal a Empresa

El usuario podrá convertir su cuenta de tipo Personal a Empresa proporcionando CIF (validado), nombre comercial, descripción, web y teléfono de empresa.

RF-23

Gestión de Métodos de Pago

El usuario podrá añadir tarjetas de crédito/débito mediante Stripe (con SetupIntent), ver las tarjetas guardadas (mostrando marca, últimos 4 dígitos y fecha de vencimiento) y eliminarlas.

RF-24

Exportación de Datos Personales

El usuario podrá descargar un fichero JSON con todos sus datos almacenados en el sistema (derecho de acceso, art. 15 RGPD).

RF-25

Eliminación de Cuenta

El usuario podrá solicitar la eliminación de su cuenta confirmando la acción (requiere escribir "ELIMINAR" y verificar contraseña o confirmar si es usuario OAuth). La cuenta se marcará como eliminada (soft-delete) y el email se anonimizará, preservando la integridad referencial de la base de datos (derecho al olvido, art. 17 RGPD).

4

Marketplace y Publicaciones Autenticado

RF-26

Publicación de Productos de Segunda Mano

El usuario podrá publicar anuncios de segunda mano mediante un asistente en tres pasos:

  • Paso 1: Selección de categoría y condición del artículo.
  • Paso 2: Título, descripción (con editor de texto enriquecido y plantillas predefinidas), imágenes (múltiples, con arrastre para reordenar y soporte de pegado desde portapapeles), marca y modelo.
  • Paso 3: Precio (con opción de marcar como negociable), tipo de oferta (VENTA, INTERCAMBIO, DONACIÓN), configuración de envío (peso y precio) y ubicación geográfica.

El sistema validará el contenido del título y la descripción contra la lista de palabras prohibidas antes de aceptar la publicación.

RF-27

Publicación de Vehículos

El usuario podrá publicar anuncios de vehículos mediante un asistente en cuatro pasos: selección del tipo de vehículo, detalles técnicos (marca desde buscador externo, modelo, año, kilómetros, combustible, cambio, potencia, color, puertas, plazas, ITV, garantía), condición y precio, y descripción con imágenes.

RF-28

Publicación de Ofertas / Chollos

El usuario podrá compartir ofertas de tiendas externas proporcionando la URL del producto (el sistema extraerá automáticamente el favicon y nombre de la tienda), título, descripción, precio original, precio de oferta, tienda, código de descuento, categoría, tipo de oferta (online o presencial), gastos de envío e imágenes. El sistema calculará y mostrará en tiempo real el badge correspondiente.

RF-29

Gestión de Publicaciones Propias

El usuario podrá, desde su panel de perfil, gestionar sus publicaciones activas:

  • Editar cualquier campo del anuncio, incluyendo imágenes.
  • Cambiar el estado del producto (DISPONIBLE, RESERVADO, VENDIDO).
  • Pausar y reactivar anuncios.
  • Eliminar el anuncio (soft-delete).
  • Renovar un anuncio expirado, reiniciando su ciclo de vida a 180 días.

RF-30

Sistema de Votación Spark / Drip

Los usuarios registrados podrán votar las ofertas y productos de la comunidad con Spark (👍 positivo) o Drip (👎 negativo). El sistema admite cambiar el voto y cancelarlo (toggle). La puntuación resultante determina el ranking de chollos en tiempo real.

RF-31

Favoritos

El usuario podrá guardar y eliminar productos, vehículos y ofertas en su lista de favoritos. Los cambios se reflejarán inmediatamente en la interfaz (optimistic UI) y serán revertidos si la operación falla en el servidor.

RF-32

Bloqueo de Usuarios

El usuario podrá bloquear a otros usuarios desde su perfil público. Los usuarios bloqueados no verán sus anuncios mutuamente en búsquedas, y no podrán enviarse mensajes entre sí.

5

Proceso de Compra y Pagos Autenticado

RF-33

Proceso de Checkout

El usuario comprador podrá adquirir un producto a través de un proceso guiado que incluye:

  • Selección del método de entrega: envío a domicilio (con selección de transportista: Correos, SEUR, MRW), recogida en punto de conveniencia o entrega en mano.
  • Introducción o selección de dirección de entrega con opción de guardarla como predeterminada.
  • Aplicación de cupones de descuento (validados en tiempo real).
  • Pago con tarjeta nueva (Stripe Card Element) o con tarjeta guardada previamente.
  • Visualización del desglose de costes: precio del producto, envío y comisión de Nexus.

RF-34

Negociación de Precio por Chat

El usuario comprador podrá proponer un precio alternativo al vendedor directamente desde el chat de la conversación del producto. El vendedor podrá aceptar o rechazar la propuesta. Si es aceptada, el precio negociado se usará automáticamente como base del pago en el checkout.

RF-35

Seguimiento del Estado de la Compra

El comprador y el vendedor podrán consultar el estado de cada transacción mediante un timeline visual que refleja los hitos: Pago Confirmado, Enviado, Entregado, Completada. El comprador recibirá notificaciones en cada cambio de estado.

RF-36

Confirmación de Recepción

El comprador podrá confirmar la recepción del producto, lo que liberará los fondos al vendedor y permitirá emitir una valoración. Si el comprador no confirma en un plazo de 7 días desde la entrega registrada, el sistema confirmará automáticamente la transacción.

RF-37

Gestión de Devoluciones

El comprador podrá solicitar una devolución de un producto en estado ENTREGADO o COMPLETADO dentro de los 7 días siguientes a la entrega. El proceso requiere la selección de un motivo, descripción detallada (mínimo 50 caracteres) y fotografías de evidencia (obligatorias salvo en cambio de opinión). El vendedor podrá aceptar o rechazar la solicitud. Una vez el vendedor confirme la recepción de la devolución, se iniciará automáticamente el reembolso en Stripe.

RF-38

Valoración del Vendedor

El comprador podrá valorar al vendedor (de 1 a 5 estrellas) con un comentario opcional una vez completada la transacción. Cada compra admite una única valoración. El sistema detectará automáticamente las compras pendientes de valorar y sugerirá emitirla al usuario.

RF-39

Respuesta a Valoraciones

El vendedor podrá responder públicamente a cualquier valoración recibida, una única vez por valoración.

6

Envíos y Logística Autenticado

RF-40

Gestión del Envío por el Vendedor

El vendedor recibirá un código de envío único (SHIP-XXXXXXXX) con código QR para depositar el paquete en la oficina del transportista seleccionado. Podrá introducir el número de seguimiento real proporcionado por el transportista. El sistema mostrará los puntos de recogida más cercanos con enlace a Google Maps.

RF-41

Seguimiento del Envío

El comprador podrá consultar el estado del seguimiento de su paquete en tiempo real, con actualización automática periódica desde la API del transportista.

RF-42

Cálculo de Tarifas de Envío

El sistema calculará automáticamente el coste de envío en función del peso del paquete y del transportista seleccionado (Correos, SEUR, MRW), mostrando el desglose antes de confirmar la compra.

7

Interacción Social y Comunicación Autenticado

RF-43

Chat en Tiempo Real

El usuario podrá mantener conversaciones en tiempo real con otros usuarios, asociadas a un producto concreto o como mensajes directos. El chat soporta los siguientes tipos de contenido: texto, imágenes, vídeos, mensajes de audio grabados en la aplicación y GIFs animados. El sistema mostrará confirmaciones de entrega (✓✓) y de lectura (✓✓ azules) en tiempo real, así como el indicador "escribiendo..." con debounce.

RF-44

Notificaciones en Tiempo Real

El usuario recibirá notificaciones instantáneas mediante WebSocket para los eventos relevantes (nuevos mensajes, compras, cambios de estado de envío, alertas de caducidad de anuncios, etc.). Las notificaciones se mostrarán como toasts en la interfaz y se registrarán en el centro de notificaciones. El usuario podrá marcarlas como leídas (individual o todas), destacarlas y eliminarlas.

RF-45

Comentarios en Ofertas

Los usuarios podrán comentar las ofertas publicadas para compartir información adicional, alertar de cambios de precio o resolver dudas de la comunidad.

RF-46

Reportes de Contenido

El usuario podrá denunciar cualquier contenido inapropiado (usuarios, productos, ofertas, vehículos, mensajes o comentarios), seleccionando el motivo de la denuncia y añadiendo una descripción detallada. Las denuncias serán revisadas por el equipo de administración.

8

Actor Empresa Empresa

RF-47

Consulta de Contratos Publicitarios Propios

La empresa podrá consultar el listado de todos sus contratos publicitarios con el estado actual de cada uno y los detalles de cada propuesta recibida del equipo de administración.

RF-48

Aceptación y Pago de Contratos

La empresa podrá aceptar una propuesta de contrato recibida del administrador, lo que redirigirá a una sesión de pago segura en Stripe Checkout. Una vez completado el pago, el contrato pasará a estado ACTIVE y el contenido patrocinado comenzará a mostrarse en la plataforma.

RF-49

Rechazo de Propuestas

La empresa podrá rechazar una propuesta de contrato que no sea de su interés.

9

Actor Administrador Admin

RF-50

Panel de Control y Estadísticas

El administrador dispondrá de un panel de control con métricas clave del sistema: total de usuarios, productos activos, compras realizadas, ingresos por comisiones (diarios, mensuales y anuales), top vendedores, últimas transacciones y últimos reportes pendientes.

RF-51

Gestión de Usuarios

El administrador podrá:

  • Listar y buscar todos los actores del sistema con sus datos completos.
  • Verificar manualmente la cuenta de un usuario.
  • Suspender temporalmente una cuenta (indicando duración y motivo).
  • Banear permanentemente una cuenta (con motivo visible al usuario).
  • Desbanear una cuenta baneada.
  • Marcar y desmarcar un usuario como sospechoso de fraude (flag interno, no visible al usuario).
  • Crear nuevas cuentas de administrador.

RF-52

Moderación de Contenido

El administrador podrá revisar, pausar (con motivo visible al vendedor), despausar, destacar y eliminar productos, ofertas y vehículos. Podrá gestionar la lista de palabras prohibidas que se aplican automáticamente al publicar cualquier contenido.

RF-53

Gestión de Reportes

El administrador podrá ver el listado de denuncias pendientes, consultar el detalle de cada una y resolverla (tomando acción sobre el contenido denunciado) o desestimar la denuncia.

RF-54

Gestión de Contratos Publicitarios

El administrador podrá crear propuestas de contrato para cualquier empresa registrada (tipo BANNER o PUBLICACION, con duración y precio), actualizar el estado de contratos existentes y eliminar contratos.

RF-55

Gestión de Categorías

El administrador podrá crear, editar (nombre, icono, color, orden, estado activo) y eliminar categorías del árbol jerárquico. No podrá eliminar una categoría que tenga contenido activo asociado.

RF-56

Gestión de Cupones de Descuento

El administrador podrá crear, editar, activar y desactivar cupones de descuento, configurando tipo (porcentaje o importe fijo), valor, alcance, límites de uso y vigencia.

RF-57

Soporte de Administrador (Takeover)

El administrador podrá ver todas las sesiones de soporte activas, tomar el control de cualquier conversación (reemplazando al bot de IA), responder mensajes directamente al usuario, emitir reembolsos desde la interfaz de soporte y cerrar sesiones. Podrá también solicitar una encuesta de satisfacción al usuario al finalizar.

RF-58

Auditoría y Trazabilidad

Todas las acciones administrativas sensibles (verificar, suspender, banear, resolver reporte, emitir reembolso) quedarán registradas en un log de auditoría inmutable con el administrador responsable, la acción realizada, la entidad afectada, la IP de origen y el timestamp.

RF-59

Notificaciones Masivas

El administrador podrá enviar notificaciones in-app personalizadas a usuarios específicos del sistema.

RF-60

Gestión de Compras y Reembolsos

El administrador podrá consultar el historial completo de compras del sistema y forzar el reembolso total de cualquier transacción en caso de disputa o resolución a favor del comprador.

10

Soporte al Usuario Público Autenticado

RF-61

Chat de Soporte con IA

El sistema dispondrá de un asistente virtual de soporte (widget flotante) accesible desde cualquier página. El bot responderá preguntas frecuentes sobre envíos, pagos, devoluciones y cuenta en español, con un tono cercano y profesional. El sistema mantendrá el historial de los últimos 10 mensajes como contexto para cada respuesta.

RF-62

Escalación a Agente Humano

El sistema detectará cuando el usuario solicita hablar con una persona real y mostrará la opción de escalación al equipo de soporte humano. Si un administrador está disponible, podrá tomar el control de la conversación en tiempo real.

RF-63

Encuesta de Satisfacción del Soporte

Al finalizar una sesión de soporte, el sistema podrá solicitar al usuario una valoración de la atención recibida (1 a 5 estrellas) con un comentario opcional.

Requisitos No Funcionales

Seguridad y Privacidad

RNF-01

Autenticación Stateless con JWT

El sistema implementará autenticación completamente stateless basada en tokens JWT. El servidor no mantendrá estado de sesión. Cada token incluirá un campo jwtVersion que permite la invalidación masiva inmediata de todos los tokens de un usuario (al cerrar sesión en todos los dispositivos, al completar el onboarding o al eliminar la cuenta). El interceptor HTTP del frontend verificará la caducidad del token en cada petición y lo eliminará localmente si está expirado.

RNF-02

Almacenamiento Seguro de Contraseñas

Las contraseñas se almacenarán exclusivamente como hashes bcrypt generados por el PasswordEncoder de Spring Security. Ningún componente del sistema tendrá acceso a las contraseñas en texto plano. El campo password estará marcado con @JsonIgnore y nunca se incluirá en ninguna respuesta JSON de la API.

RNF-03

Comunicación Segura (HTTPS)

Todas las comunicaciones entre el cliente y el servidor se realizarán exclusivamente mediante HTTPS en el entorno de producción. El frontend en Vercel (nexus-app.es) y el backend en Render (api.nexus-app.es) estarán servidos únicamente sobre TLS.

RNF-04

Protección CSRF y CORS

La protección CSRF está deshabilitada intencionalmente (arquitectura REST stateless sin cookies de sesión). La política CORS será explícita y restrictiva, permitiendo exclusivamente los orígenes autorizados: dominios nexus-app.es, subdominios mediante patrón wildcard (*.nexus-app.es) y despliegues de preview en Vercel (*.vercel.app). No se admitirá el patrón * (cualquier origen) en ningún entorno.

RNF-05

Protección contra Bots y Abuso

Los formularios de registro y recuperación de contraseña estarán protegidos con Google reCAPTCHA v2. El sistema implementará rate limiting en el endpoint de login; si se superan los intentos permitidos, la respuesta incluirá un código 429 y el frontend mostrará un contador de espera al usuario.

RNF-06

Cumplimiento RGPD

El sistema garantizará el cumplimiento del Reglamento General de Protección de Datos (RGPD / GDPR) mediante los siguientes mecanismos:

  • Derecho de acceso (art. 15): Los usuarios podrán exportar todos sus datos en formato JSON en cualquier momento.
  • Derecho al olvido (art. 17): Los usuarios podrán eliminar su cuenta, lo que resultará en un soft-delete con anonimización del email (deleted_{id}@nexus.deleted), preservando la integridad referencial.
  • Consentimiento informado (art. 7): El newsletter utilizará double opt-in. Se registrará la IP, la fecha y la versión de la política de privacidad aceptada en cada suscripción.
  • Derecho de supresión del newsletter: Cada email incluirá un token de baja único. El usuario podrá darse de baja sin necesidad de iniciar sesión.
  • Aceptación explícita de T&C: Los usuarios deberán aceptar los términos y condiciones durante el registro, almacenándose la versión aceptada y la fecha.

RNF-07

Moderación de Contenido Automática

El sistema aplicará un filtro automático sobre el título y la descripción de cualquier publicación antes de persistirla. El filtro usará una lista base de términos prohibidos combinada con una lista dinámica configurable por el administrador en tiempo real desde el panel de administración, sin necesidad de reiniciar el servidor.

Rendimiento y Escalabilidad

RNF-08

Carga Inicial Optimizada (Lazy Loading)

Todas las rutas del frontend Angular utilizarán carga diferida (loadComponent). El bundle inicial de la aplicación será mínimo; los módulos de cada sección se cargarán únicamente cuando el usuario navegue a ellas, reduciendo el tiempo de carga inicial.

RNF-09

Paginación Universal

Todos los listados del sistema utilizarán paginación del lado del servidor con Page<T> y parámetros page y size. El frontend implementará scroll infinito con IntersectionObserver en el buscador y el feed móvil para una experiencia fluida sin botones de paginación.

RNF-10

Índices de Base de Datos

Las tablas con alto volumen de consultas dispondrán de índices declarados explícitamente: idx_producto_vendedor, idx_producto_estado, idx_producto_categoria, idx_oferta_activa, idx_oferta_spark, idx_compra_comprador, idx_reporte_estado, idx_notif_actor.

RNF-11

Caché de Consultas Frecuentes

El backend implementará caché Spring Cache con TTL en las consultas de alta frecuencia y baja variabilidad: categorías raíz, todas las categorías activas y subcategorías por padre. El caché se invalidará automáticamente al crear, editar o eliminar categorías. El tamaño máximo del caché estará acotado para proteger el heap en entornos con memoria limitada.

RNF-12

Optimismo en la Interfaz (Optimistic UI)

Las acciones de alta frecuencia (añadir/eliminar favoritos, toggles de votos) se reflejarán inmediatamente en la interfaz del usuario sin esperar la respuesta del servidor. Si la petición falla, el estado se revertirá automáticamente para mantener la consistencia.

Reglas de Negocio

RNF-13

Ciclo de Vida de los Anuncios (Caducidad)

Los anuncios de productos y vehículos tendrán una vigencia de 180 días desde su publicación. Un scheduler diario a las 8:00h verificará los anuncios próximos a caducar y enviará avisos al vendedor con 30, 14, 7 y 1 día de antelación (cada aviso se envía una única vez). Al caducar, el anuncio pasa a estado EXPIRADO y permanece visible durante 14 días adicionales antes de ocultarse.

RNF-14

Sistema de Escrow en Pagos

Los fondos de una compra no se transferirán al vendedor hasta que el comprador confirme la recepción del producto. El dinero quedará retenido por Stripe (escrow) durante todo el proceso. Si el vendedor no realiza el envío dentro del plazo configurado (por defecto 10 días), el sistema procesará automáticamente un reembolso total al comprador mediante un scheduler que se ejecuta cada hora.

RNF-15

Confirmación Automática de Compra

Si el comprador no confirma la recepción del paquete en un plazo de 7 días desde que el envío registra estado ENTREGADO, el sistema marcará la compra como COMPLETADA automáticamente y liberará los fondos al vendedor.

RNF-16

Escala de Comisiones de Nexus

El sistema aplicará automáticamente la comisión de Nexus en función del precio final de cada transacción:

Rango de precioComisión
Menos de 20 €1,60 €
De 20 € a 100 €3,60 €
De 100 € a 1.000 €5,60 €

El precio máximo permitido por transacción es de 1.000 €.

RNF-17

Badge Automático de Ofertas

El sistema asignará automáticamente el badge visual de una oferta en función de sus características:

  • GRATUITA: si el precio de oferta es ≤ 0 €.
  • EXPIRA_HOY: si la fecha de expiración está en las próximas 24 horas.
  • NUEVA: si fue publicada hace menos de 1 hora.
  • CHOLLAZO: si el descuento es ≥ 70 %.
  • PORCENTAJE: si el descuento es ≥ 40 %.

RNF-18

Ranking de Chollos en Tiempo Real

El sistema recalculará el ranking de ofertas según su puntuación Spark (sparkCount - dripCount) cada 5 minutos mediante un scheduler. El resultado se publicará automáticamente a todos los clientes conectados a través del canal WebSocket /topic/ranking, sin necesidad de que el usuario recargue la página.

RNF-19

Reputación del Vendedor Dinámica

La puntuación de reputación del vendedor (0.0–5.0) se recalculará automáticamente tras cada nueva valoración recibida como la media aritmética de todas las puntuaciones otorgadas por los compradores. La reputación se mostrará en el perfil público y en el detalle de cada anuncio.

RNF-20

Restricciones de Seguridad en Transacciones

El sistema aplicará las siguientes restricciones de seguridad en las operaciones comerciales:

  • Un usuario no podrá comprar sus propios productos.
  • Dos usuarios que se hayan bloqueado mutuamente no podrán ver sus anuncios en búsquedas ni comunicarse por chat.
  • Los usuarios baneados o suspendidos no podrán iniciar sesión ni realizar ninguna operación en el sistema.
  • El precio máximo de una transacción está limitado a 1.000 €.
  • El límite máximo de imágenes por publicación es de 5 fotografías en la galería más la imagen principal.
  • El máximo de ofertas destacadas simultáneas en el banner principal es de 3.

Técnicos, Infraestructura e Integraciones

RNF-21

Comunicación en Tiempo Real (WebSocket STOMP)

El sistema implementará comunicación bidireccional en tiempo real mediante el protocolo STOMP sobre WebSocket con fallback a SockJS (HTTP polling). Los canales de comunicación son:

  • /topic/chat/{roomId}: mensajes de una conversación concreta.
  • /user/{actorId}/queue/notificaciones: notificaciones privadas por usuario.
  • /topic/ranking: ranking de chollos actualizado periódicamente.
  • /topic/chat/{roomId}/leidos y /recibidos: confirmaciones de estado del mensaje.

La autenticación de la conexión WebSocket se verificará mediante JWT en el interceptor WebSocketAuthInterceptor en el momento de establecer la conexión.

RNF-22

Almacenamiento Externo de Medios (Cloudinary)

Todas las imágenes y vídeos subidos por los usuarios se almacenarán en el servicio externo Cloudinary con optimización automática de calidad y formato. El sistema eliminará los medios de Cloudinary al borrar el contenido asociado. Las imágenes no se almacenarán directamente en la base de datos del sistema.

RNF-23

Integraciones con Servicios de Pago (Stripe)

Todos los pagos del sistema pasarán exclusivamente por Stripe. El sistema utilizará:

  • PaymentIntents: para el proceso de compra de productos.
  • SetupIntents: para guardar tarjetas de crédito/débito sin cargo inmediato.
  • Checkout Sessions: para el pago de contratos publicitarios por empresas.
  • Refunds API: para reembolsos totales y parciales automáticos y manuales.

El webhook de Stripe (/api/webhooks/stripe) estará protegido mediante verificación de firma HMAC. Las claves secretas de Stripe nunca se incluirán en el repositorio de código fuente.

RNF-24

Asistente Virtual de Soporte con IA (Gemini)

El chatbot de soporte utilizará la API de Google Gemini (modelo gemini-2.0-flash-lite) para generar respuestas contextuales en español. El sistema enviará a la API los últimos 10 mensajes de la conversación como contexto. En ausencia de clave de API configurada, el sistema recurrirá a respuestas heurísticas locales predefinidas para los temas más frecuentes (envíos, pagos, devoluciones). La clave de API se gestionará exclusivamente mediante variables de entorno, nunca en el código fuente.

RNF-25

Compatibilidad y Diseño Responsivo

El frontend será compatible con las versiones actuales de los principales navegadores (Chrome, Firefox, Safari, Edge). El diseño se adaptará a dispositivos móviles mediante una capa de UI específica para pantallas de hasta 768 px, con componentes diferenciados: cabecera móvil simplificada, barra de navegación inferior tipo app nativa (Home, Explorar, Publicar, Mensajes, Perfil) y feed de contenido tipo scroll infinito. En pantallas desktop se mostrará el layout clásico con cabecera completa y mega menú.

RNF-26

Tareas Programadas del Sistema (Schedulers)

El sistema ejecutará de forma automática las siguientes tareas en segundo plano:

TareaFrecuenciaFunción
Caducidad de anunciosDiario a las 08:00 hExpira anuncios y envía avisos preventivos (30/14/7/1 días)
Control de plazos de envíoCada horaReembolso automático si el vendedor no envía en el plazo
Confirmación automática de entregaCada horaCompleta la compra si el comprador no confirma en 7 días
Ranking de chollosCada 5 minutosRecalcula puntuaciones Spark y publica el ranking por WebSocket
Desactivación de ofertas expiradasCada horaDesactiva ofertas cuya fecha de expiración ha pasado
Actualización de trackingPeriódico configurableConsulta el estado actualizado del paquete al transportista
Fin de pausas de productosPeriódicoReactiva productos cuya pausa de administrador ha concluido
Nota sobre integraciones externas: El sistema hace uso de los siguientes servicios de terceros en producción: Stripe (pagos), Cloudinary (medios), Google OAuth 2.0 y Gemini AI (autenticación e IA), Google reCAPTCHA (anti-bots), TOTP via dev.samstevens (2FA), ZXing (generación de QR), Correos (logística), Nominatim / OpenStreetMap (geocodificación) y Google AdSense (publicidad). Las credenciales de todos estos servicios se gestionan exclusivamente mediante variables de entorno en el servidor.

Diagrama UML

Diagramas de clases, secuencias y casos de uso.

Contenido pendiente de redactar...

Mockup Interactivo Figma

Como parte de nuestro Proyecto de Fin de Grado, desarrollamos una demo conceptual durante el primer trimestre para definir la experiencia de usuario y la identidad visual de Nexus. Este prototipo interactivo sirvió como base para la implementación final, la cual se asemeja fielmente a este diseño original pero construida sobre una arquitectura robusta en Angular, utilizando Ionic + Capacitor para su compilación multiplataforma y garantizando una experiencia web completamente responsive.

Vista General del Proyecto (Diseño)

Prototipo Interactivo (App)

Interacciones funcionales del prototipo:

  • Autenticación: Registrarse con Email e Iniciar sesión.
  • Navegación (Inicio): Acceder al Perfil y usar el Buscador.
  • Barra de Navegación: Funcionalidad (Inicio, Categorías, Subir, Favoritos y Mensajes).