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

Arquitectura Propuesta (Layered, no Hexagonal)

Diagrama de arquitectura propuesta:

Diagrma Arquitectura.drawio.png

Decisiones Arquitectónicas Clave

¿Por qué 2 bases de datos separadas?

Patrón Database per Service. Cada microservicio es dueño de sus datos. Si me-cuentas se cae, ms-clientes sigue operando. Esto es la base de la autonomía en microservicios. Si comparten base de datos, no son microservicios reales, son un monolito distribuido.

¿Por qué Layered Achitecture dentro de cada microservicio y no Hexagonal?

Esto es porque se trata de una prueba, es decir, es un sistema acotado. Hexagonal (puertos y adaptadores) brilla en sistemas con múltiples fuentes de entrada/salida. Aquí cada servicio tiene una sola entrada (REST) y una salida (JPA + RabbitMQ).

Usan capas limpias (Controller → Service → Repository) con DTOs bien definidos demuestra Clean Code sin sobre-ingeniería.

Hexagonal sería viable, pero para el alcance actual, Layered Architecture cumple con los principios SOLID sin complejidad innecesaria.

¿Qué se comunica por RabbitMQ?

Cuando se crea/actualiza/elimina un Cliente, ms-clientes publica un evento. ms-cuentas lo consume para mantener una referencia local del cliente (eventual consistency). Esto evita que ms-cuentas haga llamadas HTTP síncronas a ms-clientes cada vez que necesita el nombre del cliente para el reporte.

¿Por qué no API Gateway?

Para 2 microservicios en Docker Compose, un Gateway (Spring Cloud Gateway) añade complejidad sin beneficio real. Cada servicio expone su puerto directamente.

En producción con más servicios, agregaría un API Gateway para routing centralizado, rate limiting y autenticación. Para esta prueba, se opta por mantener simplicidad.

</aside>