Usar paquetes (gemas, huevos, etc.) para crear arquitecturas desacopladas

El problema principal

Al ver el buen soporte de las plataformas más modernas de programación tienen para la gestión de paquetes (piense gem, npm, pip, etc.), ¿tiene sentido para diseñar una aplicación o sistema integrado por paquetes desarrollados internamente, con el fin de promover y crear una arquitectura de acoplamiento flexible?

Ejemplo

Un ejemplo de esto sería crear paquetes para el acceso a la base de datos, así como para la autenticación y otros componentes del sistema. Estos, por supuesto, también usan paquetes externos. Luego, su sistema importa y usa estos paquetes, en lugar de incluir su código dentro de su propia base de código.

Consideraciones

Para mí, parece que esto promovería el desacoplamiento del código y ayudaría a la mantenibilidad, casi de una manera basada en la Web frente a una aplicación de escritorio (las actualizaciones se aplican casi automáticamente, una base de código único para una funcionalidad única, etc.).

¿Parece esto un concepto de diseño racional y sensato? ¿Es esto realmente utilizado como una forma estándar de estructurar aplicaciones hoy en día?

He estado involucrado en proyectos como este dos veces ahora (ambos usando nuget con .NET), y diría que a fin de cuentas es una buena idea. Pero tu kilometraje puede variar.

No piense ni por un minuto que es una panacea, que va a resolver todos sus problemas sin causar nuevos. La administración de versiones obtendrá una nueva capa de complejidad, tendrá que lidiar con problemas de dependencia de versiones que nunca supo que existían, y tendrá momentos en los que maldecirá la decisión porque debe actualizar cuatro paquetes diferentes debido a un pequeño error que necesita corregir y liberar rápidamente.

Por otro lado, tienes razón en que desacopla las cosas muy bien. A menos que lo exagere, probablemente encontrará más ocasiones en las que piense "oh, eso funcionó muy bien" que "eso agregó mucho esfuerzo". Si tiene código compartido entre múltiples aplicaciones, es particularmente efectivo porque puede actualizar fácilmente sus aplicaciones de forma independiente.

Y, si eres como yo, rápidamente comenzarás a escribir aplicaciones de prueba que usan tus paquetes, para eliminar capas enteras de aplicaciones de tu proceso de búsqueda de errores. Y eso, en sí mismo, puede valer más que los costos.

Esta es una buena idea, en general. Tendrá que pensar en configurar un repositorio de paquetes interno (generalmente llamado "repositorio de artefactos" en el mundo de Java, o "servidor pypi" en el mundo de Python), de modo que mantenga allí los paquetes que no desea o no puede " t liberar como código abierto.

Como ha señalado @pdr, prepárese para tener su propia dependencia de infierno , donde un cambio en algún paquete requiere primero otro cambio en otro paquete, y esto significa no solo cambiar una línea de código, sino probarlo, posiblemente obtener los cambios aceptados, crear una versión y subir la versión al repositorio de paquetes mencionado anteriormente. Y luego cambiando lo que pretendías cambiar.

La única receta que puedo darle desde mi experiencia para intentar minimizar esto: no confíe únicamente en abstraer conceptos comunes de sus paquetes en un paquete "común" o "marco" . Esto puede parecer algo muy objetivo, pero conducirá a un paquete de monstruos que necesita cambios y lanzamientos frecuentes y posiblemente contradictorios. Mucho mejor, piense en las funcionalidades de su sistema y cree un paquete de ayuda para cada uno de ellos, como lo describió en su pregunta.

Aparte de eso, el principal beneficio que obtendrá es que sus aplicaciones están aisladas de (muchas) dependencias, por lo que puede intercambiarlas sin dolor.