Creo que no exagero si afirmo que todos, en algún momento (proyecto) de nuestra dilatada experiencia en el desarrollo de software, hemos implementado la típica biblioteca xxx_commons_xxx.jar. Una solución de diseño o implementación para tratar de no repetir código y poder reutilizarlo en diferentes módulos, (micro)servicios de nuestro proyecto. Una solución que en determinados casos puede ser interesante, pero de la cual tomaría como la norma general: NO LO HAGAS.
Lo que puede parecer una buena idea en un principio, desembocará en problemas de mantenimiento, escalabilidad, acoplamiento y «problemas distribuidos». Agravado si estamos hablando de múltiples servicios (o microservicios) que hacen uso de dicha librería. Todo empeora si además la librería que compartes es de persistencia (grito de horror). Imaginad, si no lo habéis padecido, que implica un cambio de añadir una columna a una tabla, si la librería es compartida por 5 (o más) servicios.
Lo dicho, mala idea compartir modelos de dominio, persistencia o modelos de infraestructura (intercambio o dto). A mi parecer esto es un indicador de un pobre diseño y una incorrecta aplicación del DDD (Domain-Driven Design).
Una mala práctica, que está mas extendida de lo que parece, incluso en grandes consultoras.
Hay bastante literatura e incluso discusiones al respecto, pero vuelvo a repetir, si quieres mantener mejor tu software, no acoples con librerías comunes de tu cosecha. Dejo algún enlace de interés al respecto:
https://www.adictosaltrabajo.com/2017/01/12/comunicacion-entre-microservicios-compartimos-codigo/ https://rltsistemas.blogspot.com/2016/02/10-consejos-la-hora-de-implantar.html
Por otro lado, si que podría ser buena idea implementar librerías comunes de utilidades, que se puedan reutilizar en diferentes proyectos. Herramientas horizontales que ahorren trabajo :).
No me cabe la menor duda, de que habrá objeciones respecto a la opinión que expongo, y como siempre estoy abierto a comentar y debatir.
Comentarios