Resumen
Durante el proceso de creación de una aplicación desde cero, en general buscamos convenciones o buenas prácticas para poder crear un proyecto escalable y actualizable en el tiempo, sin embargo, existen veces en que los estándares que se utilizan dificultan mas el trabajo a largo plazo, sobre todo cuando se trata de una aplicación que deberá ir creciendo en el tiempo.
A modo de ejemplo, si tenemos una aplicación con por ejemplo cuatro módulos principales:
- Login
- Productos
- Ventas
- Ayuda
La estructura inicial estándar de este proyecto sería la siguiente:
Luego, al agregar componentes, quedará de la siguiente forma, con los componentes de las páginas ya creados.
Luego los componentes a modo de ejemplo quedarían de la siguiente forma.
Esta estructura no es un problema en sí, sin embargo, al realizar trabajo en equipo se puede presentar la siguiente situación, por ejemplo si tenemos un componente de producto con la siguiente estructura.
Y este componente esta siendo utilizado en distintas paginas (De forma independiente a si es correcto en la lógica de la aplicación).
Entonces, si tenemos una modificación de la pagina productos, que requiere la actualización del componente producto, y a su vez en la pagina de ventas se quiere mejorar la experiencia de usuarios y también se cambia este componente, se generará un problema que requerirá, o bien separar el componente para ventas y productos o bien, trabajar en conjunto para actualizar un único componente lo que podría causar problemas o bien degradar la velocidad de desarrollo.
Otro posible problema es el hecho de requerir una pagina en otra aplicación y podamos reutilizar el código de esta aplicación, este trabajo requerirá sacar la pagina, clases, componentes, interfaces, servicios y dependencias de módulo principal para poder utilizarlo.
Esto en sí, no es un problema si lo que se busca es realizar una aplicación que sea escalable y mantenible, en absoluto, el punto es que para trabajo en equipo y para la realización de nuevas aplicaciones y productos, una alternativa puede ser estructurar el proyecto de la siguiente forma (Tomando como base el mismo ejemplo anterior).
En donde cada carpeta será un sub modulo completamente conteniendo su propia lógica de forma independiente en la aplicación, por lo que cada módulo podrá tener la siguiente estructura.
Para crear esto de forma sencilla, podemos utilizar los siguientes comandos, por ejemplo, para crear el componente de productos con el modulo y enrutador, utilizamos:
ng g c producto
ng g m producto --routing
El primer comando corresponde a la creación del componente “producto”, el segundo, corresponde a la creación del modulo y el enrutador dentro de producto, no es necesario indicar subcarpetas. Puesto que será el componente “main” de nuestro submodulo.
De forma alternativa, se puede crear sin componente principal, de forma que únicamente se ejecute este comando:
ng g m producto --routing
En este caso, tendriamos que posteriormente crear las paginas para tener un componente inicial, de las rutas.
De esta forma la organización y actualizaciones del proyecto se realizarán por módulos, los cuales serán independientes para trabajar y consumir diferentes end-points o microservicios, sin afectar la lógica de la aplicación.
Esta guía se basa en las recomendaciones del profesor Fernando Herrera, pueden ver más detalles de este tema en su video de explicación.
En mi caso, en proyectos profesionales como personales ha sido de gran ayuda para el trabajo en equipo.
Finalmente, a continuación adjunto el enlace al repositorio de una aplicación con esta estructura de ejemplo, no contiene ningun tipo de biblioteca puesto que la idea es ver el ejemplo en código puro.