El diagrama se generó con el project graph de Nx 22.5.4 del workspace (npx nx graph --print). Incluye dependencias directas detectadas entre proyectos, no todas las dependencias entre clases ni cada relación interna de una feature.
nebula-shell-e2e tiene una dependencia implícita de la aplicación que prueba.| Grupo | Proyectos |
|---|---|
| Aplicación y E2E | nebula-shell, nebula-shell-e2e |
| Funcionalidades | accounting, budget, company, invoicing, login, maestros, products, tesoreria, vault, layout, assets |
| Compartidos y capas de datos | shared-ui, shared-master, shared-data-access, shared-domain, shared-util, domain, data-access |
El project graph refleja la configuración y los imports del workspace al momento de generarlo. Puede cambiar cuando se agregan imports, rutas lazy, proyectos o implicitDependencies.
apps/nebula-shell/src/main.ts inicia la aplicación con bootstrapApplication(App, appConfig). Es una aplicación standalone: el arranque se configura mediante providers y componentes standalone, no depende de un AppModule raíz tradicional.
app.config.ts concentra providers de aplicación, entre ellos:
provideRouter(routes) para el enrutamiento.provideHttpClient(withInterceptors(...)) para HTTP e interceptores.nebula-ui-kit, iconos, idioma, perfiles y configuración API.apps/nebula-shell/src/app/app.routes.ts conecta las rutas de acceso público y las funcionalidades del ERP. La ruta /layout envuelve las páginas de negocio y usa authGuard. Las features se cargan por rutas de librería; varias se importan dinámicamente con import('@nebula/...'), de modo que Nx registra dependencias dinámicas y Angular puede dividir la carga por feature.
La ruta pública del login se consume desde @nebula/login. Las áreas de contabilidad, tesorería, presupuesto, maestros y facturación exportan sus propios árboles de rutas.
Las pantallas y muchos componentes se declaran con standalone: true. Cada componente enumera sus dependencias de plantilla en imports, recibe datos por inputs, emite eventos y compone controles de nebula-ui-kit con componentes compartidos y locales.
Las pantallas complejas suelen mantener un componente principal que coordina formulario, navegación, autorización y guardado; las secciones secundarias encapsulan partes del formulario y se comunican con el padre mediante inputs/outputs.
Se usan servicios Angular con inject(...) y providers como providedIn: 'root' para capacidades globales. La composición de dependencias globales vive en app.config.ts; servicios con estado propio de una pantalla también pueden proveerse localmente en el componente para delimitar su ciclo de vida.
App / rutas de feature
↓
Componentes Angular (UI, formularios, eventos)
↓
Store de feature (estado de pantalla/listado, si aplica)
↓
libs/data-access (servicios de negocio y APIs)
↓
libs/shared/data-access (HttpService, auth, CRUD común)
Componentes y servicios consumen contratos desde libs/domain.
libs/domain: modelos, DTOs, enumeraciones, constantes y validadores de negocio.libs/data-access: servicios de API organizados por funcionalidad; consume domain y shared-data-access.libs/shared/data-access: infraestructura transversal como HttpService, auth, interceptores, configuración API y CRUD reutilizable.libs/shared/ui: piezas visuales comunes.libs/shared/master: selectores/diálogos compartidos de maestros.libs/shared/domain y libs/shared/util: contratos y utilidades técnicas transversales.Los alias de TypeScript en tsconfig.base.json (@nebula/... y @nebula-shared/...) establecen los puntos de importación pública. Cada librería expone sus símbolos desde src/index.ts; las features deben evitar depender de rutas internas profundas.
El workspace combina Angular Signals para estado reactivo local y de servicios, RxJS para operaciones HTTP/streams, y formularios reactivos para captura/validación. Un store de feature suele coordinar paginación, filtros, selección, operaciones CRUD y drafts; el servicio se ocupa del protocolo HTTP y el componente de la interacción de usuario.
Nx descubre proyectos desde project.json y package.json, y construye aristas mediante imports estáticos, imports dinámicos y dependencias implícitas. El grafo permite entender el impacto de una librería: al cambiar shared-data-access, por ejemplo, Nx puede identificar features y proyectos que dependen de ella.
Comandos útiles desde la raíz:
npx nx show projects
npx nx graph
npx nx graph --focus=nebula-shell
npx nx graph --print
--focus permite centrar el diagrama en un proyecto y sus relaciones. --print imprime el project graph serializado para inspección automatizada.
Los targets dependen del tipo de proyecto. Por ejemplo, los paquetes libs/shared/* usan @nx/angular:package; domain y data-access usan @nx/js:tsc. Las features no necesariamente tienen un target build declarado individualmente en su project.json actual, aunque Nx puede conocerlas como proyectos por sus metadatos y dependencias.
Consultar cada project.json antes de asumir que todos los proyectos tienen los mismos targets. Desde la raíz, Nx permite ejecutar targets declarados con npx nx <target> <proyecto>.
~21.1.0 según package.json.22.5.4 según la instalación local del workspace.