metis-desk/docs/arquitectura/capas-del-servidor.md
David e3f92fa534 feat: initialize pnpm workspace and add configuration files
- Added pnpm-workspace.yaml to define package structure.
- Created prepare-local-env.py script for local environment setup.
- Introduced tsconfig.json for TypeScript configuration.
- Added turbo.json for task management with Turbo.
2026-10-03 12:36:03 +02:00

2.9 KiB

Capas del servidor

Esta es la fuente normativa de la arquitectura de Metis Desk.

Organización

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.

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.

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, flujo HTTP, contratos y pruebas.