metis-desk/docs/arquitectura/composicion-de-modulos.md
David ba562ad06f Refactor documentation for clarity and accuracy
- Updated examples in "estructura-web-por-entidades-y-operaciones.md" to reflect correct entity names and directory structures.
- Clarified modal usage and component interactions in "impresoras-del-perfil.md".
- Adjusted component descriptions in "logotipos-de-companias.md" for consistency.
- Revised persistence model details in "normalizacion-de-la-persistencia.md" to remove outdated references and clarify relationships.
- Enhanced dialog patterns in "patron-de-dialogos.md" with specific guidelines for field labels and validation.
- Specified component reuse in "patron-de-listados-de-entidades.md" to include @repo/rdx-ui components.
- Updated implementation status in "personas-y-departamentos.md" to reflect current features and pending tasks.
- Clarified project scope and initial setup instructions in "plan-de-desarrollo.md" and "puesta-en-marcha.md".
- Improved descriptions of workstation management in "puestos-de-trabajo.md" for better understanding of active/inactive states.
- Enhanced resource management details in "recursos-campos-y-plantillas.md" to clarify relationships and pending features.
- Revised best practices review in "revision-de-buenas-practicas.md" to reflect current project status and components.
- Updated teleworking documentation in "teletrabajo.md" to include references to remote technical assistance.
- Clarified user account management in "usuarios-y-acceso.md" to emphasize the importance of account deactivation.
2026-10-15 17:48:46 +02:00

1.5 KiB

Composición de módulos

Cada módulo funcional tendrá un composition root explícito: construye sus dependencias y devuelve únicamente las APIs necesarias para sus consumidores.

Usar constructor injection. No usar Service Locator, contenedores DI, decoradores ni resolución implícita. No copiar el registro dinámico del ERP: esta aplicación todavía no necesita esa capacidad.

Las rutas reciben dependencias ya construidas. No construyen repositorios, servicios de Application ni mappers de dominio.

Cuando sea necesario distinguir superficies:

  • services: servicios públicos consumidos por otros módulos.
  • internal: dependencias privadas necesarias para las rutas del propio módulo.

No exportar repositorios ni modelos ORM a otros módulos. No crear contratos públicos sin consumidores.

Superficie web de los módulos

Al crear un módulo con código de navegador o ampliar uno existente, aplicar la estructura web por entidades y operaciones. ./client apunta a src/web/index.ts cuando exista una API web pública con consumidores. Ese índice compone contratos internos explícitos; no expone automáticamente todas las entidades, operaciones o componentes del módulo. ./common y ./module mantienen sus fronteras de contratos compartidos y composición del servidor.

Core expone registerCoreRoutes mediante ./module, una frontera de composición del servidor. ./common expone contratos y ./client expone la página y recursos de traducción. No hay dependencias locales del ERP.