David
0e7106f30c
- Updated "Ficha del proyecto UECKO.md" to clarify architectural boundaries and continuity rules. - Revised "README.md" to enhance structure and clarify sources of truth for documentation. - Improved "backend.md" with clearer definitions of responsibilities and architectural layers. - Streamlined "convenciones.md" to emphasize naming conventions and TypeScript best practices. - Enhanced "datos-persistencia.md" to specify persistence rules and data integrity measures. - Updated "frontend.md" to define frontend rules and state management practices. - Refined "testing.md" to clarify testing levels and validation processes. - Revised "vision-general.md" to outline system architecture and module boundaries more clearly.
2.1 KiB
Visión general de arquitectura
Objetivo
Definir los límites arquitectónicos transversales del sistema, sin detallar la implementación interna de cada capa.
Sistema y módulos
La aplicación gestiona tiempos, tareas, actividad, incidencias y procesos de Oficina Comercial y Oficina Técnica. Ambos son módulos funcionales diferenciados y cada uno es propietario de los datos que genera.
Los módulos pueden consultar información ajena cuando sea necesario, pero solo colaboran mediante servicios públicos explícitos. No se comparten repositorios, modelos ORM, mappers internos, servicios internos de escritura ni detalles de Infrastructure. Un módulo no modifica datos propiedad de otro sin permiso expreso.
Estilo y límites
El backend sigue DDD pragmático, Clean Architecture y arquitectura hexagonal. Se priorizan claridad y explicitud frente a abstracción prematura; esos principios no justifican crear capas, adaptadores, factories, genéricos, eventos o contenedores de DI sin una necesidad actual.
La dirección general de dependencias es:
Domain
no conoce Application ni Infrastructure
Application
depende de Domain, contratos y Core
no conoce Express, Sequelize ni modelos ORM
Infrastructure
depende de Application, Domain y Core
Cada módulo mantiene su propio composition root, que construye explícitamente sus dependencias. No se permite Service Locator ni DI implícita o mágica. Antes de cambiar una frontera arquitectónica se deben identificar productores, consumidores y efectos derivados.
Límites transversales
La aplicación y los datos permanecen separados. Las actualizaciones y migraciones no pueden destruir, sobrescribir ni exigir reintroducir información histórica. Las reglas técnicas que materializan estos límites se definen en datos y persistencia; los contratos de cada capa, en backend.