|
|
|
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áctica<sup>28</sup>, genera referencias circulares en las dependencias de Maven ya que los módulos `demeter-data` y `demeter-servicios` dependerían el uno del otro. |
