ms-clientes → Microservicio (Cliente, Persona)

<aside>

Contenido

</aside>

<aside>

Dependencias - Spring Boot 4.0.3

Spring Web
Spring Data JPA
PostgreSQL Driver
Spring for RabbitMQ
Validation (Bean Validation con Jakarta)
Spring Boot Actuator (health checks para Docker)
Lombok
Spring Boot DevTools (hot reload en dev)

open-in-view: false - application.yml

Se deja en false porque esta propiedad mantiene la sesión de Hibernate abierta durante toda la petición HTTP, incluyendo la serialización JSON.

Como estamos emplenado microservicios esto puede causar queries N+1 silenciosas y problemas de performance. Descativarlo nos obliga a cargar todo lo que necesitamos en el Service.

Estrategia de Herencia - Open/Closed de SOLID

JPA nos ofrece 3 estrategias de herencia, pero para este test la que mejor se acopla es JOINED.

SINGLE_TABLE: Una sola tabla con columna discriminatoria. Rápido en queries pero las columnas de Cliente quedarían en NULLs en filas de Persona. No es limpio.
TABLE_PER_CLASS: Tablas completamente separadas sin relación FK. Rompe la normalización.
JOINED: Una tabla personas y una tabla clientes con FK a personas.
- Normalizado, limpio y profesional. Cada tabla tiene sus columnas. Es más lento en queries por el JOIN pero para este volumen no es tan relevenate.
- Cada tabla es responsable de sus propios campos, y la relación se mantiene por FK. Para volúmenes altos consideraría SINGLE_TABLE por performance, pero para este dominio la claridad del modelo es prioritaria.
- Para este dominio donde solo tenemos Cliente (no hay otros subtipos de Persona), JOINED es mas limpio y aplica mejor JPA.

Por ejemplo, si tuviéramos Administrativo, Proveedor… cada uno tendría su propiea tabla con solo sus campos específicos, y todos comparten personas.

Herencia.drawio.png

Con SINGLE_TABLE todo estaría en una sola tabla con muchos NULLs:

Elegimos JOINED pensando en extensibilidad. El modelo de Persona como entidad base permite agregar nuevos subtipos sin modificar la tabla existente. Si mañana el negocio necesita más entidadees que hereden de Persona, solo la agregamos y JPA crea su tabla. Las tablas existentes no se tocan, este es el principio Open/Closed de SOLID aplicado al modelo de datos.

Ids Internos y Ids de negocio Externos

El id Long es interno en Clientes, el clienteId UUID es el identificador de negocio para uso externo. La comunicación entre microservicios es “externa”, entonces usamos el UUID para referencial al cliente en Cuentas.

Si depués migramos la base de datos de ms-clientes y los IDs auto-incrementales cambian, todas las cuentas quedan apuntando a IDs incorrectos. Pero el UUID nunca cambia.

Los microservicios se counican exclusivamente por identificadores de negocio, nunca por PKs internos. Esto garantiza desacoplamiento total, cada servicio puede migrar o reestructurar su base de datos sin afectar al otro.

Para movimientos y cuentas no aplica esto, porque viven en el mismo microservicio y la misma base de datos. El ceuenta_id en movimientos es un FK interno, controlado por JPA con @ManyToOne. Nadie externo lo consume.

La regla que seguimos es simple:

Comunicación interna (dentro del mismo microservicio) → Long autoincremental. Es más eficiente para índices, joins y FK.
Comunicación externa (entre microservicios o expuesto al cliente) → UUID. Desacoplado y seguro.

Si mañana otro microservicio necesitara referencair un movimiento específico, ahí sí agregaríamos un movimientoId UUID como identificador de negocio. Por ahora nadie externo referencia movimientos, así que no se necesita. Seguimos aplicando YAGNI, no lo agregamos hasta que lo necesitamos.

Contraseña

Las contraseñas se almacenan hasheadas con BCrypt. Es un algoritmo one-way con salt automático, cada hash es único aunque la contraseña sea la misma. Esto protege los datos incluso si la base de datos es comprometida.

</aside>