Gestión de comedores escolares con control de alergias

Problema

Un comedor escolar maneja datos que no admiten fallo: qué alumno tiene qué alergia y qué hay que hacer si ocurre algo. Cuando eso vive en hojas de cálculo y listados impresos, la información se duplica, envejece y nadie sabe cuál es la versión buena.

Solución

Una API organizada por dominio, con cada módulo cerrado sobre sí mismo: modelo, configuración de persistencia, repositorio y controlador. Los alumnos, las alergias y su relación son entidades propias, de forma que una alergia se define una vez y se asocia, en lugar de escribirse a mano en cada ficha.

Todas las entidades heredan auditoría y borrado lógico, porque en este dominio interesa saber quién cambió qué y poder recuperar un registro retirado por error.

Arquitectura

Decisiones técnicas

• Módulos por dominio en vez de carpetas por tipo técnico: el código de alergias vive junto, no repartido entre cuatro directorios.
• Configuraciones de EF Core separadas por entidad, fuera del contexto.
• Entidad base con auditoría y borrado lógico heredada por todo el modelo.
• Frontend en Server Components, con el estado de sesión resuelto en servidor.

Resultado

Backend modular con los dominios de usuarios, alumnos y alergias, y frontend Next.js consumiendo la API. Proyecto en evolución: la parte de alumnos y alergias está modelada y pendiente de terminar su capa de exposición.