David
ba562ad06f
- 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.
62 lines
3.2 KiB
Markdown
62 lines
3.2 KiB
Markdown
# Capas del servidor
|
|
|
|
Esta es la fuente normativa de la arquitectura de Metis Desk.
|
|
|
|
## Organización
|
|
|
|
```text
|
|
apps/
|
|
server/ arranque, configuración y middleware HTTP común
|
|
web/ arranque React, proveedores y composición de páginas
|
|
modules/
|
|
core/
|
|
src/
|
|
common/ contratos Zod y traducciones compartidos
|
|
api/ código exclusivo del servidor
|
|
web/ páginas, consultas y acceso HTTP del navegador
|
|
packages/
|
|
typescript-config/ configuración compartida del compilador
|
|
```
|
|
|
|
Los módulos funcionales seguirán esta estructura. Dentro de api, crear domain, application e infrastructure cuando existan responsabilidades que lo requieran.
|
|
|
|
En módulos existentes y nuevos, el código de `web` debe organizarse por entidad o área
|
|
funcional y después por operación, con ámbitos compartidos e índices explícitos según la
|
|
[estructura web por entidades y operaciones](../estructura-web-por-entidades-y-operaciones.md).
|
|
|
|
El endpoint de salud solo comprueba la vida del proceso y no necesita agregados, repositorios ni casos de uso. Los módulos de negocio utilizan las capas según sus responsabilidades.
|
|
|
|
## Dependencias
|
|
|
|
Infrastructure → Application → Domain.
|
|
|
|
Domain no conoce Express, Zod de transporte, Sequelize, Application ni Infrastructure.
|
|
Application conoce Domain, contratos y puertos necesarios; no importa Express, modelos ORM ni Infrastructure.
|
|
Infrastructure implementa HTTP y persistencia. Los puertos de repositorio se declaran en Application; sus implementaciones concretas viven en Infrastructure.
|
|
|
|
common puede ser consumido por servidor y navegador. Nunca exporta modelos ORM ni infraestructura.
|
|
La aplicación web importa únicamente contratos comunes y la API pública web de los módulos.
|
|
|
|
Cada módulo mantiene sus propios repositorios. La colaboración entre módulos se realiza mediante servicios públicos explícitos, únicamente cuando existan consumidores reales.
|
|
|
|
## Creación y persistencia
|
|
|
|
create valida invariantes de creación y devuelve Result. Application lo usa para nuevas entidades.
|
|
rehydrate reconstruye entidades persistidas sin aplicar reglas de creación ni emitir eventos. Infrastructure lo usa al leer.
|
|
update aplica sus propias invariantes; no reutiliza create ni rehydrate.
|
|
|
|
Los Value Objects se reconstruyen mediante create. Un fallo al leer datos persistidos se trata como inconsistencia de persistencia, no se oculta.
|
|
|
|
Cada agregado persistido tendrá un mapper bidireccional con toPersistence y toDomain.
|
|
Sequelize permanece en Infrastructure. El módulo de identidad ya usa MariaDB y Sequelize v6.
|
|
|
|
Toda entidad de negocio lleva un UniqueID. Las declaraciones DDD y reglas de UUID se definen en [Modelo DDD e identificadores](modelo-ddd-e-identificadores.md).
|
|
|
|
## Alcance de las abstracciones
|
|
|
|
Result, Maybe y Collection seguirán el estilo del ERP cuando tengan consumidores reales.
|
|
No se copia rdx-utils completo ni se depende del filesystem de factuges-erp.
|
|
No se generan módulos vacíos para funciones futuras.
|
|
|
|
Consultar también [composición](composicion-de-modulos.md), [flujo HTTP](flujo-http.md), [contratos](contratos-http.md) y [pruebas](pruebas.md).
|