FactuGES_ERP/docs/backend-prompt-base.md
David dac22372b9 feat(docs): archive legacy DTO design and naming guidelines, introduce HTTP request flow, module boundaries, and testing guidelines
- 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.
2026-09-08 23:40:49 +02:00

2.0 KiB

DEPRECATED — Backend Prompt Base

Este documento es AUXILIAR y no establece arquitectura. Para reglas vigentes, consultar arquitectura normativa.

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