Arquitectura de microservicios modelos de dominio compartido

Supongamos que tenemos una aplicación Spring Boot que utiliza la arquitectura de microservicios. Cada uno de los servicios tiene sus propios modelos de dominio, pero cada servicio debe hacer referencia a un objeto de dominio de Usuario. ¿Cuál sería el mejor enfoque sobre cómo resolver este problema? ¿Sería mejor para cada servicio tener un ID de usuario y luego, cuando sea necesario, solicitar al servicio del usuario los detalles del usuario, o sería mejor tener una biblioteca de dominio compartida para todos los microservicios?

Si eligió los microservicios para beneficiarse de la escalabilidad, el acoplamiento flojo y la fácil modificación independiente de cada servicio, debe atenerse a él en la mayor medida posible.

Arquitectura general

Creo que el mejor enfoque sería:

• tener un microservicio para la gestión general de la información del usuario;
• mantener información específica del usuario del microservicio (p. ej., perfiles, autorizaciones, preferencias) en cada microservicio (utilizando la referencia del ID general)

Lectura adicional:

• Este artículo describe muy bien este tipo de arquitectura y lógica, con el caso específico de las autorizaciones.
• Este artículo describe los desafíos y la solución para la gestión de la identidad del usuario, para evitar que todos los servicios accedan al mismo repositorio.
• Este artículo describe cómo utilizar JWT para pasar la identidad del usuario entre los servicios (señalando que se puede proporcionar cierta información básica en el token de identificación, lo que evita tener que consultar el servicio del usuario una vez más después del inicio de sesión, al menos para los datos muy básicos). información).

Código compartido

Ahora, si está de acuerdo con la solución anterior, tenemos un microservicio de usuario (modelo de dominio encapsulado para el usuario) y todos los demás servicios son consumidores del mismo microservicio. La pregunta es entonces saber si quieres:

• cada microservicio para reinventar el código del consumidor, siguiendo el dogma de una fuerte separación para permitir ciclos de liberación flexibles y distintos,
• o para compartir el código del consumidor como parte de la biblioteca, considerando que esta información fundamental es una extensión del patrón de infraestructura del "chasis" .

No tomaré una posición clara al respecto, ya que hay guerras de opinión opinadas sobre este tema de código compartido, y no creo que esté en condiciones de tomar una posición objetiva. Aquí ya hay algunas lecturas adicionales:

• Este artículo cree que no hay una mejor solución, y todo depende de sus objetivos.
• La posición de este artículo es que el código compartido es malo solo si crea un acoplamiento fuerte, y el código compartido puede traer algunas sinergias
• Este artículo (de personas que implementaron microservicios a escala) insiste en la necesidad de tener compilaciones separadas y los posibles problemas de desmantelamiento del código anterior. Tener una biblioteca compartida para consumir con la gestión de versiones sólidas no impide estas buenas prácticas.

Mi propia opinión al respecto es que NO DEBE COMPARTIR el código entre el usuario-proveedor y los usuarios-consumidores, a fin de evitar un acoplamiento estrecho. Sin embargo, PODRÍAS COMPARTIR el código de consumo del usuario entre los consumidores si tienes una sólida administración de versiones. Este enfoque tendría algunas ventajas:

• Se podrían construir diferentes microservicios consumidores de usuarios con diferentes versiones del código compartido de consumo de usuarios (siempre que las versiones sean compatibles con el proveedor de usuarios independiente). Misma flexibilidad que reinventando la rueda pero mayor productividad.
• Puede cambiar su servicio de proveedor de usuario de forma independiente sin afectar a los consumidores.
• Si se encuentra un error en el lado del consumo, puede corregirlo una vez e implementar a todos los consumidores como lo mejor (gracias a la gestión de versiones). Esto incluso podría conducir a una mayor calidad de servicio.
• Si, por algún motivo, está obligado a actualizar la API de usuario-proveedor, puede implementar el consumo de usuario actualizado más rápidamente. Si mantiene activo el servicio de proveedor antiguo y nuevo durante la transición, esta posibilidad de compartir podría permitir el desmantelamiento más rápido de la versión anterior del consumidor-proveedor.

Evitaría una biblioteca compartida si es posible. Pregúntese qué propiedades de un usuario necesita cada servicio? A menudo, hay un dominio central donde vivirá la mayor parte del comportamiento que rodea a un usuario, y los dominios de soporte a menudo solo necesitan un ID de usuario.

Si su servicio necesita otros detalles sobre un usuario, eche un vistazo a algunas sugerencias aquí sobre cómo manejar tales situaciones