Compartir objetos DTO entre microservicios

Navega tus respuestas
14

TL; DR: ¿Puedo compartir una biblioteca POJO entre servicios?

En general, nos gusta mantener el intercambio entre los servicios estrictamente limitado a ninguno si es posible. Ha habido cierto debate sobre si el servicio que está compartiendo datos debe proporcionar una biblioteca cliente para que los clientes la utilicen. El cliente-lib es generalmente opcional para que un cliente del servicio lo use y puede consumir la API, sin embargo, le agradan, ya sea para usar el cliente-lib o para usar un lenguaje alternativo y usar los aspectos generales de la biblioteca y demás. p>

En mi caso, estoy considerando un servicio que crea un objeto de datos. Asumamos que este objeto es un PET. NO es la entidad de la base de datos, sino estrictamente un POJO que representa implícitamente los datos subyacentes. Este POJO es lo que la API ha definido. Suponga: mascota: edad, peso, nombre, propietario, dirección, especie, etc.

Servicio 1 - PetKeeper: generará una mascota por cualquier motivo, conservará todos los datos y deberá hacer referencia a este servicio para obtener la mascota o realizar modificaciones en la mascota. Digamos el nombre los cambios o el cambio de dirección se deben realizar a través de una llamada a la API de este servicio.

Servicio 2 - PetAccessor: este servicio reúne a las mascotas y realiza comprobaciones de validación

Servicio 3,4 : más llamadas de servicio intermedio

Servicio 5 - Interfaz de usuario

Estos son muy arbitrarios, pero el punto es simple. La UI o algún servicio orientado al usuario desea presentar de alguna manera este objeto "PET". Debe llamar a través de una API a un servicio, que llama a un servicio, que llama a un servicio, etc., hasta que llega al servicio que reúne la información requerida y comienza la retransmisión. Finalmente, el servicio de interfaz de usuario tiene el objeto PET para mostrar.

Esto es bastante común, pero con nuestra mentalidad absoluta, duplicamos el objeto PET en cada servicio. El principio DRY (no se repita) solo se aplica al código DENTRO de un servicio y no se aplica a todos los servicios, pero el punto sigue ahí. Que tal si agregamos un campo ... debemos modificar 5 servicios del POJO en cada uno.

--OR-- Podemos proporcionar una Pet-Objects-Library que contiene algunos de los pojo de la API y cada servicio puede importar / depender de la biblioteca. No hay dependencia de los servicios en sí, sino solo de la biblioteca general. Me gusta esta idea para que cada servicio tenga el mismo tipo de objeto y las actualizaciones sean más fáciles. Pero me preocupan los objetos de Dios.

¿Qué son los pros / contras? ¿Cuál es el mejor diseño? ¿Qué has hecho para pasar datos entre servicios para minimizar la repetición de las mismas clases de POJO y al mismo tiempo permanecer desconectado?

    
pregunta Aerith 28.11.2016 - 07:27

3 respuestas

5
  

¿Cuál es el mejor diseño?

Puede reutilizar el mismo objeto Pet DTO entre los servicios backend (que procesan la lógica de negocios típica), pero cuando se trata del nivel de presentación (Interfaz de usuario), generalmente es una es una buena práctica usar un FormBean (un bean diferente con campos agregados para la lógica de presentación) para que haya una clara separación entre la lógica de presentación y la lógica de negocios .

Esto es necesario porque los servicios deben ser reutilizables y un único servicio puede ser expuesto / reutilizado por múltiples / diferentes puntos finales (como la interfaz o podría ser un servicio web diferente, etc.) y cada uno de ellos los puntos finales pueden requerir campos adicionales que serán rellenados por los respectivos Controladores o capas (como adaptadores) sobre los servicios.

  

¿Qué has hecho para pasar datos entre servicios para minimizar la repetición?   ¿Las mismas clases de POJO a la vez que permanecen desconectadas?

Si utiliza un solo bean entre los niveles de negocio y web, está uniendo firmemente la lógica de presentación con la lógica de negocio , lo que no es una buena práctica y terminará cambiando los servicios por un requisito en el Frontend (como, por ejemplo, un formato de fecha diferente que se mostrará en la interfaz de usuario). Además, para hacer este proceso de rellenar / copiar los datos a través de los beans (como DTO a FormBean o Viceversa), puede usar bibliotecas como Apache BeanUtils.copyProperties() o Dozer para evitar el código de plantilla .

    
respondido por el developer 28.11.2016 - 07:47
4

Si el DTO representa la misma entidad comercial en todos los microservicios, solo debe haber una clase, compartida entre los servicios. Es (casi) nunca correcto tener código duplicado para el mismo objeto.

    
respondido por el Jim Garrison 28.11.2016 - 07:42
0

La forma en que planeo hacerlo ahora, es que cada servicio empaqueta los DTO y los pone en Nexus como jar lib. Cuando otro servicio lo necesite, obtendrá estas librerías DTO como dependencia en manve / gradle. Si se lanza una nueva versión DTO en un solo servicio, está bien siempre que la versión anterior también sea compatible al mismo tiempo, así que no rompa la compatibilidad con versiones anteriores, las versiones, etc. así que esta es el área de back-end-back-end. También para evitar la dependencia de la circulación, es mejor que separe el servicio del paquete dto

Ahora mire backend-to-frontend y viceversa No estoy de acuerdo con los comentarios anteriores de que la interfaz de usuario como capa de presentación es diferente. ¡NO ES! La IU es solo otro microservicio para mí que también consume y produce eventos.

Dirección del backend-to-frontend Lo que hago es convertir POJO (dtos) a las interfaces y paquetes de Typescript en NPM y cargarlos también en Nexus. El proyecto basado en UI nodejs luego consume y usa esos. Esta es la forma de servicio a la interfaz de usuario.

Dirección de frontend a backend Para la UI para los eventos de la capa de servicio, convierto las interfaces Typescript y las convierto a POJOs (dtos), empaqueté como jar y las cargué en Nexus (o algún repositorio) en forma de jar para ser consumidas por los servicios de back-end.

Estos procesos se manejan fácilmente mediante procesos de CI (Travis, Gitlab CI, etc.)

Cualquier comentario a este enfoque es bienvenido.

    
respondido por el kensai 09.11.2017 - 19:58

Lea otras preguntas en las etiquetas

¿Por qué Microsoft eliminó el modelo RESX para RESW en las aplicaciones de la Tienda Windows? ¿Cuál es la forma correcta de anidar los recursos en el modelo REST?
Comentarios Recientes

se ejecuta en la capa de enlace, lo que puede dificultar la definición de jerarquías de recursos compartidos. Tome ngBy y ngByProvider para ilustrar: ngByProvider. ngBy ('by objectName'). trivialTypeToWebView (). replyTo (objectName) .deleteFrom (objectName) es una instancia de este objeto en http://example.com/requests/dotg/2034 (tenga en cuenta el atributo "by in view" - esto es útil para cambiar el tipo de datos en un objeto). Y aunque siempre mantengo el contexto en el que los contenedores en otros centros de... Lee mas