Arquitectura de dominio, no una demo con datos falsos
KADI está escrito como un sistema de dominio clínico-financiero: la visita es la entidad central, y el resto del modelo se deriva de ella. Esta página describe el stack y la arquitectura reales, con evidencia verificable durante el proceso de evaluación técnica.
Stack
| Capa | Tecnología |
|---|
De la visita nacen el expediente, la cuenta y la hospitalización
Este es el mapa de dependencias real entre entidades del sistema, tal como está documentado en el inventario técnico del repositorio.
Cliente 1──N Paciente 1──N Visita 1──1 Cuenta 1──N Cargo ──N──1 Producto
│ │ └─1──N CuentaPago
│ └─0..1 Hospitalizacion 1──N {Evento, SignoVital, AplicacionMedicamento}
├─1──N Expediente
└─1──N ProcedimientoPreventivo (vacunas, desparasitación, dental, otros)
CorteCaja 1──N MovimientoCaja Usuario N──1 Rol N──N Permiso
Producto 1──N MovimientoInventario PreAdmision ──► Visita
Diagrama técnico, no una captura de interfaz. Refleja las relaciones documentadas en el inventario del repositorio.
Cómo se sostiene el código
Pruebas automatizadas
Backend cubierto con PHPUnit y frontend con Vitest, ejecutados en integración continua. Los conteos exactos de casos y aserciones se comparten en el proceso de due diligence, porque cambian con cada versión y preferimos no publicar una cifra que se desactualice sola.
Control de acceso por middleware
Los permisos se verifican en el servidor, no solo se ocultan en la interfaz: una ruta sin el rol requerido responde con error, la pantalla no es la única barrera.
Reglas de negocio como contrato
Las reglas financieras y clínicas (quién revierte un pago, quién da de alta una hospitalización, de dónde sale el precio de un cargo) están documentadas y ligadas a pruebas específicas, no solo a la memoria de quien programó.
Entorno reproducible
El sistema corre sobre Docker Compose con PostgreSQL, Nginx y los servicios de la aplicación, pensado para reproducirse en un entorno aislado durante una evaluación técnica.
Lo que ya está impuesto por el sistema
Control de acceso basado en roles
Cinco roles con una matriz de permisos por dominio clínico y financiero.
EntregadoProtección CSRF
Protección integral contra falsificación de solicitudes entre sitios en las rutas de sesión.
EntregadoAcceso controlado a evidencia clínica
La evidencia clínica sensible se gestiona bajo controles de acceso y trazabilidad; este sitio no publica rutas internas ni detalles de almacenamiento.
EntregadoRespaldo operativo para despliegues comerciales
La automatización de respaldo productivo está diferida hasta que exista un despliegue comercial autorizado; no se presenta como operación activa hoy.
RoadmapInvariantes de base de datos y concurrencia financiera
Trabajo activo para blindar operaciones financieras concurrentes ante condiciones de carrera poco frecuentes.
En endurecimientoCamino único de release y protección de rama
Unificación del proceso de publicación de versiones antes de un despliegue comercial.
En endurecimientoNo publicamos hallazgos de seguridad específicos en este sitio por responsabilidad: se comparten bajo acuerdo durante la evaluación técnica. Ver due diligence.