David
dac22372b9
- Archived historical documents for DTO design and naming conventions. - Added normative documentation for HTTP request flow and module boundaries. - Introduced testing guidelines for backend layers. - Updated onboarding module documentation and clarified onboarding requirements. - Deprecated backend prompt base and prompt auth documents. - Adjusted paths in testing documentation for consistency.
52 lines
2.0 KiB
Markdown
52 lines
2.0 KiB
Markdown
# DEPRECATED — Backend Prompt Base
|
|
|
|
> Este documento es **AUXILIAR** y no establece arquitectura. Para reglas vigentes, consultar [arquitectura normativa](./architecture/README.md).
|
|
|
|
## Objetivo
|
|
|
|
Centralizar el contexto comun para prompts de backend del ERP y evitar copiar la misma plantilla en varios ficheros.
|
|
|
|
## Contexto comun
|
|
|
|
- API en `Node.js`, `TypeScript`, `Express.js` y `Sequelize`
|
|
- Arquitectura Hexagonal, DDD pragmatico y SOLID
|
|
- Controllers responsables del contrato HTTP
|
|
- Repositorios desacoplados de Sequelize
|
|
- DTOs y presenters para respuestas
|
|
|
|
## Principios de diseno
|
|
|
|
- agregados encapsulan su estado y exponen solo lo necesario
|
|
- cada agregado usa su mapper de dominio <-> persistencia
|
|
- repositorios trabajan con agregados, no con modelos ORM expuestos
|
|
- SRP, OCP, LSP, ISP y DIP aplicados de forma explicita
|
|
- dependencias expresadas mediante interfaces de aplicacion
|
|
|
|
## Reglas tecnicas
|
|
|
|
- no usar Sequelize directamente en servicios de aplicacion
|
|
- no acoplar servicios a implementaciones concretas si ya existe contrato
|
|
- mantener transformacion a DTO en controllers o presenters
|
|
- capturar errores de persistencia y mapearlos a errores de dominio o API con semantica clara
|
|
- tipar de forma explicita entradas, salidas y resultados
|
|
|
|
## Persistencia y transacciones
|
|
|
|
- los repositorios encapsulan acceso a persistencia
|
|
- los mappers reconstruyen y serializan agregados
|
|
- las transacciones se gestionan mediante el mecanismo del proyecto, no desde el controller
|
|
- mantener convenciones existentes de tablas, columnas y timestamps
|
|
|
|
## Testing y seguridad
|
|
|
|
- cubrir servicios con tests de unidad cuando cambie comportamiento observable
|
|
- cubrir rutas con tests HTTP cuando aplique
|
|
- no exponer datos sensibles en responses
|
|
- devolver codigos HTTP coherentes con el contrato del endpoint
|
|
|
|
## Uso
|
|
|
|
- `prompt-auth.md` extiende esta base para autenticacion
|
|
- `prompt-customer-invoices.md` extiende esta base para customer invoices
|
|
- si aparece otro prompt backend, debe reutilizar esta base en lugar de copiarla
|