¿Qué tal amigos? Recientemente hicimos la votación en los LIVES, acerca del nuevo proyecto que estaremos desarrollando en vivo para la comunidad de YouTube. La democracia ganó y tenemos como nuevo proyecto un sistema para gestionar una tienda departamental.

La verdad es que este proyecto parace inconmensurable, pero a la ves es retador y se que me aportara mucha experiencia y conocimientos.

Para el proyecto Store System, hemos abandonado la fragmentación de múltiples repositorios en favor de una infraestructura centralizada que garantiza que todas las piezas del sistema evolucionen en sincronía.

Técnicamente, este proyecto se define como un Monorepo Modular basado en Workspaces con Orquestación de Build. Esta arquitectura combina la coexistencia física de múltiples proyectos con la independencia lógica de cada uno, permitiendo una agilidad de desarrollo superior.

El ADN Técnico: Los Tres Pilares

Para entender cómo funciona Store System, es necesario desglosar los componentes de su nombre técnico:

1. Monorepo Modular: A diferencia de un monolito donde todo está mezclado, aquí el código está separado en módulos independientes (apps y packages) que residen en un mismo repositorio de Git.
2. Workspaces (pnpm): Es el mecanismo que permite la resolución de módulos local. Gracias a los espacios de trabajo, una aplicación puede importar una librería interna como @store-system/types sin necesidad de publicarla en un servidor externo.
3. Orquestación de Build (Turborepo): Es la inteligencia que gestiona el ciclo de vida. Turbo entiende el grafo de dependencias y utiliza caché inteligente para no repetir tareas (builds, tests) que ya se han completado previamente.

La Filosofía: «Single Source of Truth»

El núcleo de Store System reside en sus paquetes compartidos (packages/), que actúan como la infraestructura crítica sobre la cual se asientan las aplicaciones (apps/). Al centralizar los tipos, los estilos y la lógica de base de datos, reducimos drásticamente los errores de integración.

El ecosistema de Aplicaciones

Hemos diversificado el frontend para optimizar el rendimiento según el caso de uso:

• Administración e Inventario: admin-panel y warehouse-app utilizan Vue 3 + Vite para ofrecer una experiencia de Single Page Application (SPA) reactiva y potente.
• Marketing y Ventas: La landing-page utiliza Astro, aplicando una Arquitectura de Islas que garantiza un SEO impecable al enviar el mínimo JavaScript necesario al navegador.
• Cerebro Central: La api en Express centraliza la lógica de negocio y la persistencia de datos mediante TypeScript.

El Motor de los Paquetes Compartidos

La potencia de esta arquitectura radica en cómo las aplicaciones consumen los recursos internos de manera transparente:

Paquete	Función	Impacto en el Proyecto
@store-system/types	Contratos de TypeScript.	Seguridad de tipos de extremo a extremo (E2E).
@store-system/db	Cliente de Prisma único.	Integridad de datos y modelos unificados.
@store-system/ui-theme	Tokens de diseño (SCSS).	Consistencia visual absoluta en todas las plataformas.
@store-system/ui-components	Librería de Vue.	Reutilización de componentes con comportamiento predecible.

---

Flujo de Trabajo y Rendimiento

Manejar esta complejidad requiere herramientas que entiendan la estructura. Con Turborepo, el tiempo de construcción se mantiene bajo independientemente del tamaño del proyecto.

El sistema aplica el patrón de Build Incremental: si no has modificado la lógica de un paquete, el orquestador recupera el resultado de la caché en lugar de procesarlo de nuevo.

Comandos de Operación

• pnpm install: Sincroniza y enlaza todos los workspaces mediante enlaces simbólicos.
• pnpm dev: Inicia todos los servicios de forma paralela y organizada.
• pnpm build: Compila el ecosistema respetando la jerarquía de dependencias.

---

Hoja de Ruta: Próximos Pasos

Con la arquitectura modular ya establecida, el enfoque se desplaza hacia la implementación de la lógica central:

1. Capa de Datos: Definir el esquema de Prisma y ejecutar las primeras migraciones en el paquete @store-system/db.
2. Validación de Entorno: Implementar un sistema de gestión de variables de entorno estricto para las 5 aplicaciones.
3. Estandarización: Configurar las reglas de ESLint y Prettier compartidas en @store-system/tsconfig.

Conclusión

Store System no es solo una colección de aplicaciones; es un Monorepo Modular diseñado para ser mantenible y escalable. Al separar el diseño, la lógica de tipos y la persistencia en paquetes independientes, hemos creado un entorno donde la innovación es segura y el crecimiento del código no penaliza la velocidad de desarrollo.