jhoanatanchaparro/java

This repo contains two separate Spring Boot applications, each with its own pom.xml, bootstrap class, and runtime boundaries:

1. EjercicioAutonomo is a classic layered Spring app with both server-rendered views and API-style controllers.

2. facturacion-prod is a second Spring Boot service focused on facturation/invoicing, with REST controllers, persistence, DTO mapping, and security.

1) Top-level structure: two independent applications

These are not just modules of one app; they appear to be two deployable services living side by side in the same repository. Each has its own:

• Spring Boot main class

• resources/configuration

• repository/service/controller stack

• tests

That means architecture diagrams should show them as separate bounded contexts, not a single monolith.

2) EjercicioAutonomo: domain-oriented CRUD app

This app manages a small business domain:

• Categoria

• Producto

• Proveedor

• Cliente

• Orden_Compra

• Orden_Detalle

The package layout suggests a standard flow:

Controller → Service → Repository → Entity/DB, with DTOs at the boundary.

3) Dual presentation layer in EjercicioAutonomo

This app has two controller styles:

• Controller/* for REST-like endpoints

• Controller/View/* for HTML page rendering backed by templates in src/main/resources/templates

So the app likely serves both:

• browser pages for CRUD screens

• JSON endpoints for programmatic access

That is an important boundary for the diagram: UI templates and REST endpoints are separate entry paths into the same domain services.

4) DTO + mapper boundary in EjercicioAutonomo

For each domain area there are:

• Dto/Request/*

• Dto/Response/*

• Mapper/*

That implies input/output data is intentionally decoupled from persistence entities. The services likely translate:

• request DTOs → entities

• entities → response DTOs

This is the main anti-corruption boundary between transport and persistence.

5) Persistence layer in EjercicioAutonomo

Repositories exist for each aggregate:

• CategoriaRepository

• ProductoRepository

• ProveedorRepository

• ClienteRepository

• OrdenCompraRepository

• OrdenDetalleRepository

Entities are stored under Entity/, so the app likely uses Spring Data JPA with relational persistence. The diagram should show repositories as the only layer directly touching the database.

6) External service integration in EjercicioAutonomo

This app also includes:

• Feign/ClienteFeignClient

• Controller/Feign/ClienteFeignController

• Service/Servicelmpl/ClienteFeignServiceImpl

• Config/FeignConfig

That indicates an outbound integration via Spring Cloud OpenFeign to a remote client/customer service. This is a separate flow from local CRUD:

Feign controller/service → Feign client → external HTTP service.

7) Caching and resilience concerns in EjercicioAutonomo

Config/CacheConfig.java shows a cache layer is enabled or configured. That suggests some service results may be cached, probably to reduce repeated reads or remote calls. Even if the cache backend is not visible here, it is a distinct architectural concern worth marking around the service layer.

8) Error handling in EjercicioAutonomo

Exception/GlobalExceptionHandler.java and ResourceNotFoundException.java indicate centralized exception translation. In the diagram, this sits as a cross-cutting boundary around controllers/services:

• domain/service errors are converted into HTTP responses

• not-found cases are handled consistently

9) facturacion-prod: invoice and product service

The second app is narrower and centers on:

• Factura

• DetalleFactura

• Producto

Its structure is also layered:

Controller → Service → Repository → Model/DB

This suggests a transactional invoice domain where a Factura contains one or more DetalleFactura entries.

10) DTO mapping in facturacion-prod

This app uses DTOs explicitly:

• RequestFacturaDTO

• RequestDetalleFacturaDTO

• ResponseFacturaDTO

• ResponseDetalleFacturaDTO

• ProductoDto

It also has Configuration/ModelMapperConfig.java, so object mapping is automated rather than hand-written. That means the diagram should show a DTO mapping boundary between controllers and the model layer.

11) Security boundary in facturacion-prod

Configuration/Security.java is a major architectural feature. It implies endpoints are protected and requests pass through a security layer before reaching controllers. This is the main cross-cutting boundary in this service and should be shown separately from business logic.

12) Persistence in facturacion-prod

Repositories exist for:

• FacturaReposistory

• DetalleFacturaRepository

• ProductoRepository

The model classes are under Model/, so persistence is likely JPA-based. The service layer coordinates invoice creation and product lookup, while repositories isolate database access.

13) Likely data flow in facturacion-prod

The most important runtime path is:

1. Client calls FacturaController

2. Security validates/filters the request

3. FacturaService processes invoice logic

4. Repositories persist Factura and DetalleFactura

5. DTOs are returned to the caller

ProductoController/ProductoService likely provide a supporting catalog flow used by invoices.

14) How to diagram the whole repo

A good architecture diagram should show:

• two separate Spring Boot services

• EjercicioAutonomo with:

- HTML views

- REST/API controllers

- Feign outbound integration

- cache and global exception handling

• facturacion-prod with:

- secured REST controllers

- service/repository/model layers

- DTO mapping via ModelMapper

- invoice + invoice-detail aggregate

The strongest boundary in the repo is between:

• presentation/API

• application/service logic

• persistence

• external HTTP service integration (only in EjercicioAutonomo)