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
La arquitectura definida para 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 debe mantener su propio composition root, que construya 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.