Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • demeter demeter
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 9
    • Issues 9
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Infrastructure Registry
  • Analytics
    • Analytics
    • CI/CD
    • Repository
    • Value stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Manuel de Blas
  • demeterdemeter
  • Wiki
    • 11.manual de desarrollador
  • 11.2 Estructura del backend

Last edited by ManuelDeBlas Nov 20, 2025
Page history

11.2 Estructura del backend

El backend sigue una estructura en la que cada módulo cuenta con su propio pom.xml con sus dependencias y yconfiguraciones específicas. Además, existe un pom.xml general que define la estructura completa del proyecto y el mirror al repositorio de paquetes del CESTIC. A continuación de listas los diferentes módulos:

  • demeter-aplicacion: Contiene la clase principal de la aplicación. Este es el módulo que se debe ejecutar en el IDE durante el desarrollo.
  • demeter-comun: Incluye recursos compartidos por todo el proyecto. En este proyecto concreto no se ha utilizado.
  • demeter-data: Contiene las clases del dominio, incluyendo entidades y repositorios.
  • demeter-seguridad: Contiene la lógica de seguridad y autenticación de la API.
  • demeter-servicios: Implementa los servicios de la aplicación, accediendo a los repositorios y modificando entidades. Solo contiene lógica de negocio relativa a la relación entre entidades.
  • demeter-web: Contiene los controladores que exponen los endpoints de la API.

La arquitectura de la aplicación sigue siempre la secuencia: repositorios → servicios → controladores. Nunca se accede a los repositorios directamente desde los controladores.

Asimismo, los servicios no deberían ser accedidos desde el módulo demeter-data, ya que, a parte de ser considerado una mala práctica27, genera referencias circulares en las dependencias de Maven ya que los módulos demeter-data y demeter-servicios dependerían el uno del otro.

Clone repository
  1. Especificación y formulación del problema
    1. Introducción
    2. Definición del problema
    3. Descripción del proceso actual
    4. Actores
    5. Alcance y limitaciones
    6. Analistas
  2. Estudio de Viabilidad del Sistema (EVS)
    1. Mind Map
    2. Impact Map
    3. Alternativas
      1. Sage HR
      2. OrangeHRM
      3. Deméter
      4. Matriz de decisión
  3. Especificación de Requisitos del Sistema (ERS)
    1. Planificación
    2. Historias de Usuario
    3. Product Backlog
    4. Diseño de la Interfaz de Usuario
    5. Diagramas
  4. Definición del MVP
  5. Sprint 1
    1. Sprint Planning
    2. Sprint Review
    3. Sprint Retrospective
  6. Sprint 2
    1. Sprint Planning
    2. Plan de pruebas
    3. Sprint Review
    4. Sprint Retrospective
  7. Sprint 3
    1. Sprint Planning
    2. Sprint Review
    3. Sprint Retrospective
  8. Sprint 4
    1. Sprint Planning
    2. Plan de pruebas
    3. Sprint Review
    4. Sprint Restrospective
  9. Sprint 5
    1. Sprint Planning
    2. Plan de Pruebas
    3. Sprint Review
    4. Sprint Retrospective
  10. Despliegue
  11. Manual de desarrollador
    1. Guía de instalación
    2. Estructura del backend
    3. Estructura del frontend
    4. Librerías
  12. Conclusiones
  13. Siglas
  14. Referencias
  15. Demostracion