Pero si te salvarán de repetir código y tener hacer el mismo cambio en varios proyectos.
Antes de entrar en temas de tecnologías, lenguajes, frameworks, etc, debemos recordar que, al final del día, siempre existen reglas de negocio que debemos atacar, sin excepción alguna y esa debería ser de las primeras cosas a tomar en cuenta, la lógica inherente al negocio, el problema que nuestro desarrollo solventará.
La forma de consumir la solución puede variar, ya sea un cliente de escritorio, un cli en la terminal, un servicio http, grpc, etc, etc, pero eso no debería modelar nuestra solución, incluso me atrevo a decir que deberíamos ser capaces de tener n combinaciones de todas las opciones anteriores.
En mi opinión, lo mejor para esto es separar de inicio ambas cosas, por un lado la solución a las reglas de negocio (tal cuál), y por otra la forma de consumirlo. Esto nos puede traer beneficios como:
- Tener un código más desacoplado
- Facilitar el desarrollo de tests
- Facilitar el consumo de nuestra solución
Se pueden usar varias técnicas o herramientas, dado que principalmente me muevo en el mundo de Rust y Javascript, centraré mis ejemplos en cualquiera de esos 2 ecosistemas aunque como lo mencioné al inicio, la idea principal es la de desacoplar.
Javascript
NPM nos permite por medio de los workspaces tener varios proyectos conviviendio en un mismo espacio, sin embargo en lo personal prefiero Turborepo porque aparte de estar hecha con rust, permite poder reusar caché en los builds, lo cual se traduce como un ahorro de tiempo y energía, cosas que son importantes en el día a día y para el medio ambiente si lo piensan como la sugiere la green software foundation.
Por regla Turborepo define dos directorios principales:
📁 packages
Es el lugar dónde se definen las bibliotecas. La intención es compartir código entre las bibliotecas o aplicaciones.
📁 apps
Acá deben vivir las soluciones completas que se aprovecha de las bibliotecas del directorio packages.
Rust
En el caso del ecosistema de rust, Cargo cuenta de igual forma con workspaces que si bien se definen de forma diferente a los de npm, la idea es la misma, poder tener varios proyectos y librerias en un mismo espacio permitiendo que de puedan hacer importaciones de uno a otro.
Acá el trabajo es un poco más manual, sin embargo no es nada complicado. En el archivo Cargo.toml principal, se definen los paths que podrán ser importados.
# Cargo.toml
[workspace]
members = [
"libs/ags",
"libs/organigrama",
"apps/cli",
"apps/server",
]
resolver = "2"
Y cada proyecto, ya sea una librería o no, podrá importar por medio de la ruta relativa el componente necesario.
# apps/cli/Cargo.toml
[package]
name = "cli"
version = "0.1.0"
edition = "2021"
[dependencies]
# Local
organigrama={path = "../../libs/organigrama"}
¿Y todo para qué?
¿Para qué tanto amor?
Desde la perspectiva del negocio, una entidad es la misma sin importar el contexto, por poner un ejemplo, una compra tiene formas muy similares para un cliente y para un vendedor, ¿por qué deberíamos estar repitiendo tipos o estructuras que definen lo mismo solo por que están en contextos diferentes?
De no estar centralizada esa definición, puede que se convierta en un trabajo extra del cuál debemos estar al tanto y rompe completamente con el principio DRY (Don't Repeat Yourself)
Evidentemente esto aplica siempre y cuando el lenguaje sea el mismo para los contextos.
En fin, hasta acá el post de por qué creo que deberían usarse más los monorepositorios.
En el siguiente post La quiere limpia ó hexágonal (la aquitectura jóven), ahondaremos en cómo deberíamos organizar nuestro código dentro de cada sección, sean librerías o aplicaciones.
Top comments (0)