62 lines
3.1 KiB
Markdown
62 lines
3.1 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).
|
|
|
|
La primera entrega solo comprueba la vida del proceso. No hay reglas de negocio, agregados, repositorios ni casos de uso artificiales para esta comprobación técnica.
|
|
|
|
## 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).
|