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

3.2 KiB

Raw Permalink Blame History

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.

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.

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.

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.

3.2 KiB Raw Permalink Blame History