Tecnología y arquitectura

Un backend estructurado, escalable y basado en buenas prácticas.

El backend de iMirly se ha diseñado siguiendo principios de arquitectura limpia y buenas prácticas de desarrollo, con el objetivo de garantizar mantenibilidad, escalabilidad y seguridad.

Arquitectura iMirly - Spring Boot API APP MÓVIL Android / Compose API REST Spring Boot Java + Kotlin Services JPA / H2 SEGURIDAD ✓ Autenticación JWT ✓ Control de acceso ARQUITECTURA Controllers (REST) Services (Lógica) Repositories (Datos)

Visión general del sistema

iMirly se apoya en una arquitectura cliente-servidor, donde la aplicación móvil consume una API REST desarrollada en Spring Boot.

App móvil (cliente)

Aplicación Android desarrollada con Jetpack Compose que consume servicios REST

API REST (backend)

Servidor Spring Boot que expone endpoints RESTful para la gestión de datos

Base de datos relacional

Persistencia de datos mediante JPA con base de datos H2 en desarrollo

Esta separación permite desacoplar el frontend del backend y facilita la evolución independiente de cada parte del sistema.

Arquitectura en capas

El backend sigue un patrón arquitectónico por capas que separa claramente las responsabilidades del sistema.

Capa de presentación (Controllers)

  • Exposición de endpoints REST
  • Gestión de peticiones HTTP
  • Validación básica de datos
  • Manejo de respuestas y excepciones

Capa de lógica de negocio (Services)

  • Reglas de negocio
  • Gestión de operaciones
  • Separación de responsabilidades
  • Transaccionalidad

Capa de acceso a datos (Repositories)

  • Acceso a base de datos mediante JPA
  • Abstracción de la persistencia
  • Uso de repositorios Spring Data
  • Consultas tipadas y seguras

Capa de modelo (Entities / DTOs)

  • Representación de datos
  • Separación entre entidades y DTOs
  • Mapeo objeto-relacional
  • Validaciones de dominio

Capa de seguridad (Security)

  • Configuración de autenticación
  • Filtros de seguridad HTTP
  • Gestión de roles y permisos
  • Protección contra vulnerabilidades

Capa de excepciones (Exception Handling)

  • Gestión centralizada de errores
  • Respuestas HTTP consistentes
  • Logging de incidencias
  • Mensajes informativos para el cliente

Esta estructura mejora la legibilidad, el mantenimiento y la escalabilidad del proyecto.

Modelo de datos

El modelo de datos de iMirly se ha diseñado para representar de forma clara la relación entre usuarios y servicios, permitiendo una futura ampliación del sistema.

Usuario

Entidad central del sistema

  • • id (PK)
  • • nombre
  • • email
  • • password
  • • rol (cliente/proveedor)

Servicio

Anuncio de servicio ofrecido

  • • id (PK)
  • • titulo
  • • descripcion
  • • precio
  • • usuario_id (FK)

Categoría

Clasificación jerárquica

  • • id (PK)
  • • nombre
  • • descripcion
  • • categoria_padre_id (FK)

Relaciones

Cardinalidad entre entidades

  • • Usuario 1:N Servicios
  • • Categoría 1:N Servicios
  • • Categoría 1:N Subcategorías
  • • Integridad referencial

Estructura relacional

El modelo sigue una arquitectura relacional normalizada donde los usuarios pueden publicar múltiples servicios (relación 1:N), y cada servicio pertenece a una categoría específica. Las categorías pueden anidarse jerárquicamente mediante auto-referencia.

Esta estructura garantiza la integridad referencial de los datos, facilita consultas eficientes mediante joins y permite escalar el sistema añadiendo nuevas entidades sin modificar las existentes.

Seguridad y autenticación

La aplicación contempla un sistema de autenticación basado en tokens, preparado para garantizar el acceso seguro a los recursos de la API.

Autenticación de usuarios

Sistema de login que verifica credenciales y genera tokens de sesión para usuarios válidos

Control de acceso a endpoints

Protección de rutas sensibles mediante filtros de seguridad que validan la autenticación

Preparado para JWT

Arquitectura lista para implementar JSON Web Tokens, estándar de la industria para autenticación stateless

Protección de datos sensibles

Almacenamiento seguro de contraseñas mediante hash y prevención de vulnerabilidades comunes

Nota: En fase de desarrollo se utiliza una configuración simplificada, con vistas a reforzar la seguridad en fases posteriores.

Base de datos y entorno

Durante el desarrollo, iMirly utiliza una base de datos en memoria (H2), lo que permite pruebas rápidas, facilidad de configuración y un entorno controlado.

H2 Database

  • Base de datos en memoria
  • Sin instalación externa
  • Ideal para desarrollo y testing

Datos de prueba

  • Script SQL inicial (data.sql)
  • Población automática
  • Escenarios predefinidos

Entorno portable

  • Sin dependencias externas
  • Ejecución en cualquier máquina
  • Ideal para demostraciones

Preparado para producción

  • Migración a MySQL/PostgreSQL
  • Mismo código JPA
  • Perfiles Spring (dev/prod)

Spring Data JPA

  • Abstracción de persistencia
  • Repositorios automáticos
  • Consultas tipadas seguras

API REST

  • Endpoints HTTP estándar
  • Comunicación stateless
  • Formato JSON universal

Buenas prácticas de desarrollo

Separación de responsabilidades

Cada clase tiene una única razón para cambiar, siguiendo el principio SOLID

Arquitectura en capas

Independencia entre presentación, lógica y datos

Código mantenible

Nomenclatura clara, comentarios pertinentes y estructura organizada

GET
POST

Estándares REST

Uso correcto de métodos HTTP, códigos de estado y formatos JSON

Preparado para escalabilidad

Diseño que permite crecer sin reestructurar el sistema

Git

Proyecto versionado

Control de versiones con Git y repositorio estructurado

Javadoc

Documentación de código

Comentarios Javadoc en métodos y clases para facilitar el mantenimiento

JSON

DTOs y serialización

Uso de Data Transfer Objects para separar entidades de la API pública

"Un backend bien estructurado es la base de un proyecto sostenible."

Escalabilidad y evolución futura

La arquitectura de iMirly permite incorporar nuevas funcionalidades sin necesidad de rehacer el sistema.

🏷️

Nuevos tipos de servicios

El modelo de categorías permite añadir nuevos tipos de servicios sin modificar la estructura existente.

Valoraciones y reputación

Preparado para incorporar sistema de ratings y reviews mediante nuevas entidades relacionadas.

💳

Sistemas de pago

Arquitectura lista para integrar pasarelas de pago y gestión de transacciones.

🎛️

Panel de administración

Capacidad para añadir endpoints de gestión y roles administrativos.

🗄️

Migración a BBDD real

Cambio transparente de H2 a MySQL o PostgreSQL para producción manteniendo JPA.

🔔

Notificaciones push

Estructura preparada para integrar servicios de mensajería y alertas en tiempo real.

La tecnología dentro del proyecto

La tecnología de iMirly no se ha planteado como un fin en sí mismo, sino como un soporte sólido para una solución real y escalable.

01 Arquitectura sólida
02 Código mantenible
03 Base para crecer
"Las buenas prácticas no se ven, pero se notan."

Base técnica sólida

El backend de iMirly demuestra que el proyecto se apoya en una base técnica coherente, bien estructurada y alineada con los estándares actuales del desarrollo de aplicaciones.

Siguiente sección: Equipo