<aside>

Contenido

1. Introducción
2. Stack tecnológico
3. Arquitectura de Software
4. Esquema / Diseño de Base de Datos
5. Integración RabbitMQ
6. ms-clientes → Microservicio (Cliente, Persona)
7. ms-cuentas → Microservicio (Cuenta, Movimientos)
8. Comunicación entre microservicios
9. Seguridad
10. Pruebas unitarias
11. Pruebas de integración
12. Buenas prácticas de desarrollo
13. Documentación API
14. Despliegue en Docker
15. CI/CD → AWS EC2
16. Probar solución

</aside>

<aside>

GlobalExceptionHandler con @ControllerAdvice

Un solo punto para manejar todas las excepciones. Retorna respuestas consistentes con estructura {timestamp, status, error, message, path}.

Validación con Bean Validation (@Valid)

No validamos manualmente en el Service. Usar @NotBlank, @Positive, @Size en los DTOs. Spring Boot 4 con Jakarta Validation lo maneja nativamente.

MapStruct para mapeo Entity ↔ DTO

No usamos conversiones manuales. MapStruc genera código en tiempo de compilación (zero-cost en runtime). Se elige MapStruct sobre ModelMapper porque genera código estático, no usa reflection, y es type-safe.

Idempotencia en movimientos

Cada movimiento debe ser atómico. Usar @Transactional en el Service para que la actualización del saldo y el registro del movimiento sean una sola transacción.

Versionados de API

Los endpoints deben va como /api/v1/clientes

Spring Boot 4 tiene soporte nativo para API Versioning

Rendimiento

• BigDecimal para dinero (precisión, no Double).
• @Transactional(readOnly = true) en lecturas (evita dirty-checking).
• open-in-view: false (evita queries N+1 silenciosas).
• Denormalización del nombre del cliente (evita llamadas HTTP en cada reporte).
• Índices vía constraints unique en campos de búsqueda.

Escalabilidad

• Arquitectura de microservicios (escalan independientemente).
• Database per service (no comparten BD).
• Comunicación asíncrona con RabbitMQ (desacopla los servicios).
• Docker containers (portabilidad y replicabilidad).

Resiliencia

• try/catch en ClienteRestClient (si ms-clientes está caído, la cuenta se crea sin nombre)
• Queue durable en RabbitMQ (mensajes persisten si el consumer está caído)
• Soft delete (no se pierden datos)
• GlobalExceptionHandler (errores controlados, nunca stack traces al cliente)
• Health checks con Actuator
• Retry mechanism, implementamos retry con backoff exponencial para las llamadas síncronas entre servicios. Si ms-clientes tiene un error momentáneo, el sistema reintenta antes de rendirse. Combinado con la sincronización asíncrona de RabbitMQ, el sistema es resiliente tanto a fallos transitorios como a caídas prolongadas. </aside>