Gestión de Pedidos de Repuestos B2B — PoC (Etapa 2)

Prueba de concepto de un módulo de Gestión de Pedidos de Repuestos para concesionarios y talleres que hacen pedidos de repuestos a la planta (Fanalca). Alcance deliberadamente acotado: un solo servicio backend con Clean Architecture, base de datos PostgreSQL con un procedimiento almacenado para reportes, y un frontend Angular simple. Ver el detalle de decisiones y lo que queda explícitamente fuera de alcance en docs/ARCHITECTURE.md y el diagrama C4 en docs/c4-diagram.md.

Stack

• Backend: Java 17 + Spring Boot 3, Clean Architecture (domain / application / infrastructure / presentation), Maven.
• Base de datos: PostgreSQL 16, migraciones con Flyway, procedimiento almacenado de reporte, datos semilla.
• Frontend: Angular 22 (standalone components), HttpClient, servido con nginx.
• Documentación de API: Swagger/OpenAPI (springdoc).

Ejecutar con un solo comando

Requisito: Docker y Docker Compose.

docker-compose up --build

Esto levanta 3 servicios: postgres, backend (aplica migraciones Flyway y datos semilla automáticamente al iniciar) y frontend.

URLs

Servicio	URL
Frontend	http://localhost:4200
API backend	http://localhost:8080/api
Swagger UI	http://localhost:8080/swagger-ui/index.html
OpenAPI JSON	http://localhost:8080/v3/api-docs
PostgreSQL	localhost:5432 (db pedidos, user/password pedidos)

Para detener y limpiar (incluyendo el volumen de datos, para reiniciar desde cero con el seed data original):

docker-compose down -v

Datos semilla

Al iniciar, el backend ya tiene 3 clientes, 6 productos y 5 pedidos de ejemplo en distintos estados, para poder probar la PoC sin cargar datos manualmente. El reporte de productos más pedidos puede probarse, por ejemplo, con el rango 2026-07-01 a 2026-07-31.

Estructura del repositorio

/gestion-pedidos-fanalca
├── backend/                  Java 17 + Spring Boot 3 (Clean Architecture)
│   └── src/main/java/.../{domain,application,infrastructure,presentation}
├── frontend/                 Angular 22 (standalone components)
├── docs/
│   ├── ARCHITECTURE.md       Decisiones de arquitectura y alcance
│   └── c4-diagram.md         Diagrama C4 (Nivel 1 y 2) en Mermaid
└── docker-compose.yml

Casos de uso implementados

1. Crear pedido con una o más líneas de detalle, validando stock disponible.
2. Consultar pedido por id (con sus detalles).
3. Listar pedidos por cliente, con filtro opcional por estado.
4. Cambiar estado de un pedido (PENDIENTE → CONFIRMADO → DESPACHADO, o → CANCELADO), con reglas de transición válidas.
5. Reporte de productos más pedidos en un rango de fechas (consume el procedimiento almacenado sp_reporte_productos_mas_pedidos).

Desarrollo local (sin Docker)

Backend (requiere un PostgreSQL local o el contenedor postgres del compose ya arriba):

cd backend
DB_HOST=localhost DB_PORT=5432 DB_NAME=pedidos DB_USER=pedidos DB_PASSWORD=pedidos \
  mvn spring-boot:run

Tests unitarios del dominio y casos de uso:

cd backend
mvn test

Frontend (apunta a http://localhost:8080/api por defecto en modo desarrollo):

cd frontend
npm install
npm start   # ng serve, http://localhost:4200

Fuera de alcance (a propósito)

Autenticación/autorización real, mensajería asíncrona entre microservicios, un pipeline de CI/CD completo, y cobertura de tests exhaustiva. Cada punto está justificado en docs/ARCHITECTURE.md.