Skip to content
Boost CRM

Workspaces y Boundaries

Workspaces declarados

Section titled “Workspaces declarados”
  • apps/*
  • packages/*

Regla de importación

Section titled “Regla de importación”
  • Permitido: @repo/*, @/ en web, imports locales del módulo.
  • Prohibido: imports relativos cruzando apps/packages (ej. ../../packages/...).

Ownership de capas

Section titled “Ownership de capas”
  • UI de producto: apps/web y apps/native.
  • Contratos, cliente compartido y shapes de dominio reutilizables: packages/shared-types, packages/api-client, packages/crm-services.
  • Auth/[REDACTED]s/sesión/BFF browser-safe: apps/web.
  • Infra de tipado: packages/typescript-config.

Política de capas

Section titled “Política de capas”

packages/*

Section titled “packages/*”
  • contratos
  • cliente HTTP
  • servicios de dominio
  • normalización reusable de backend -> frontend-domain
  • shapes estables que luego consumen web y mobile

apps/web

Section titled “apps/web”
  • BFF oficial de auth mobile
  • [REDACTED]s, sesión web, refresh/revocación
  • traducción de errores browser-safe
  • agregación, caché corta y orquestación server-side cuando convenga proteger/desahogar a BoostAPI

apps/web y apps/native

Section titled “apps/web y apps/native”
  • renderizado
  • estados visuales
  • interacciones específicas de plataforma
  • decisiones de densidad y UX

Decisiones de aislamiento

Section titled “Decisiones de aislamiento”
  1. No compartir pantallas completas entre web y native.
  2. No acoplar componentes web a primitives RN ni viceversa.
  3. Shared packages nunca dependen de APIs específicas de Next/Expo.
  4. No meter secretos, [REDACTED]s ni auth sensible dentro de packages/*.
  5. No volver a interpretar la respuesta raw del backend en UI si ya existe un shape normalizado en package.

Riesgos de boundary

Section titled “Riesgos de boundary”
  • Drift de contratos por bypass a shared-types.
  • Duplicación de fetch logic fuera de api-client.
  • Reglas visuales inconsistentes por saltar identidad por plataforma.
  • Encerrar demasiado dominio en apps/web/app/api/* y perder reutilización real para native.
  • Sobrecargar BoostAPI por no usar la capa server de web para caché, deduplicación o agregación cuando ya existe.

Nota de estrategia

Section titled “Nota de estrategia”
  • El estado híbrido actual del monorepo es intencional: web conecta primero, mobile sigue después por slices.
  • Mock-first en módulos incompletos no es smell automático; el problema es cuando ese mock no se distingue del flujo real esperado.