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.
1.7 KiB
Flujo HTTP
Para operaciones de negocio, usar:
RequestSchema → validación en route → Controller
→ UseCase({ dto, context }) → InputMapper → Value Objects / Props
→ servicios de Application / Domain
Las rutas declaran validación y guards de autenticación y autorización. El controller obtiene el contexto autenticado, invoca el caso de uso y traduce Result a HTTP. Application no conoce Express y no construye agregados directamente desde DTOs HTTP.
El InputMapper adapta primitivas y contexto, crea Value Objects y devuelve Result. Solo crear un RequestMapper adicional cuando exista adaptación HTTP real, como combinar body, params y query.
Los identificadores de la organización y del actor se obtienen del contexto autenticado. customerId puede identificar al cliente atendido, pero siempre se comprueba que el actor tenga acceso antes de consultar o modificar sus datos.
Salud y middleware común
GET /api/__health devuelve status y time. Rechaza parámetros de consulta desconocidos. Comprueba únicamente que el proceso responde; no demuestra disponibilidad de base de datos ni autorización. No requiere un caso de uso porque no contiene comportamiento de negocio.
Cada petición obtiene un UUID generado por el servidor, devuelto como x-request-id. Los errores HTTP tienen code y requestId. No devuelven detalles internos. El middleware registra método, estado, duración e identificador; no registra URL, query, cabeceras ni cuerpo.
El servidor escucha en 127.0.0.1. La interfaz de desarrollo usa el proxy de Vite para /api. Las rutas de datos de clientes requieren sesión autenticada y los guards correspondientes. Las escrituras validan origen y CSRF antes de ejecutar la operación.