<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>

Implementado en esta prueba:

• Contraseñas hasheadas con BCrypt: Las contraseñas nunca se almacenan en texto plano. Se utiliza BCryptPasswordEncoder de Spring Security Crypto, que aplica hashing one-way con salt automático. Cada hash es único aunque la contraseña sea la misma, protegiendo los datos.
• Contraseña no expuesta en respuestas: El ClienteResponseDto no incluye el campo contrasena. Nunca se retorna información sensible al consumidro de la API.
• Identificadores de negocio (UUID): Los microservicios se comunican por UUID (clienteId), nunca por PKs internos secuenciales. Esto evita enumeración de recursos (un atacante no puede adivinar que si existe el cliente "5" probablemente existe el "6").
• Soft Delete: Los registros nunca se eliminan físicamente. Esto protege la integridad de los datos y cumple con principios de auditoría financieraa.
• Validación de estado activo: Las entidades con Soft Delete validan su estado antes de cualquier operación de escritura. Un recurso inactivo no puede ser modificado ni operar sobre él.
• GlobalExceptionHandler: Manejo centralizado de excepciones. Nunca se exponen stack traces ni detalles internos del servidor al cliente. Las respuestas de error siguen una estructura consistente y controlada.
• Bean Validation: Validación declarativa en los DTOs de entrada (@NotBlank, @NotNull, @Min, @Max, @DecimalMin). Los datos se validan antes de llegar al Service (fail fast).

No implementado (fuera del alcance de esta prueba, pero recomendado en producción)

• Autenticación y Autorización: Implementar Spring Security con JWT o OAuth 2.1 para proteger los endpoints. Cada petición requeriría un token válido y los roles controlarían qué operaciones puede hacer cada usuario.
• Rate Limiting: Limitar la cantidad de peticiones en un periodo de tiempo para prevenir ataques de fuerza bruta y abuso de la API. Se aplicaría en múltiples niveles: por usuario autenticado (mediante el token JWT de la sesión) como control principal, y por IP como segunda capa para peticiones no autenticadas (login, registro). Se implementaría con Spring Cloud Gateway o Bucket4j.
• HTTPS/TLS: Cifrado en tránsito para que los datos no viajen en texto plano por la red. En producción se configuraría con un certificado SSL en el load balancer o reverse proxy (Nginx).
• Auditoría de operaciones: Registrar quién hizo qué y cuándo con @CreatedBy, @LastModifiedBy de Spring Data JPA Auditing.
• CORS configurado: Restringir qué dominios pueden consumir la API, evitando acceso no autorizado desde frontends desconocidos.
• Cifrado de datos sensibles en reposo: Cifrar campos sensibles en la base de datos más allá del hash de contraseñas. </aside>