Transcripción de la sesión — 12 preguntas • 47 min
01
Terminología ambigua — "Account"
El plan usa "account" para referirse tanto a la empresa cliente (Acme Corp contrata NutriTrack) como al empleado individual (el que registra comidas). Son dos cosas completamente distintas con ciclos de vida diferentes. ¿Cuál de los dos llamamos Account y cómo llamamos al otro?
Recomiendo: "Organization" para la empresa cliente y "Member" para el empleado. "Account" queda reservado solo si necesitas representar credenciales de acceso, separado del concepto de persona.
Tiene sentido. La empresa cliente es la que paga y configura el programa. El empleado es quien usa la app. Usaremos Organization para la empresa y Member para el empleado.
✓ Término resuelto: "Account" eliminado del glosario. Sustituido por Organization (empresa cliente) y Member (empleado participante). CONTEXT.md actualizado.
02
Ambigüedad de rol — "Admin" vs "Nutricionista"
El plan menciona "admin nutricional", "nutricionista" y "responsable de RRHH" como si fueran intercambiables. ¿Son el mismo rol? Si un nutricionista puede asignar planes y RRHH solo puede ver métricas agregadas, son roles con permisos muy distintos. ¿Qué roles existen realmente en el sistema?
Recomiendo: Definir dos roles bien separados: WellnessManager (nutricionista, puede asignar planes y ver datos individuales) y HRViewer (RRHH, solo dashboard agregado). Si en el futuro una persona tiene los dos, es un detalle de implementación, no de dominio.
En realidad son dos roles distintos. El nutricionista gestiona todo lo clínico y el de RRHH sólo quiere ver si el programa funciona a nivel empresa. Los llamamos WellnessManager y HRViewer.
Inconsistencia detectada: El plan decía "El nutricionista asigna un plan activo" pero también "La empresa ve métricas agregadas". La empresa no ve nada; es el HRViewer quien ve las métricas. La Organization como entidad no tiene UI directa.
✓ Términos resueltos: WellnessManager (gestiona planes y ve datos individuales) y HRViewer (solo dashboard agregado, sin acceso individual). "Admin" eliminado del glosario.
03
Decisión arquitectónica — Versionado de MealPlan
El plan dice que los nutricionistas crean "plantillas de planes semanales". ¿Qué pasa cuando el WellnessManager modifica un MealPlan que ya está asignado a 30 Members? ¿Se actualizan retroactivamente? ¿Crean una nueva versión? Si un Member hizo el seguimiento contra la versión anterior y luego el plan cambia, la adherencia histórica queda invalidada.
Recomiendo: Los MealPlans son inmutables una vez asignados. Cualquier modificación crea una nueva versión. Las asignaciones apuntan siempre a una versión específica. Así el historial de adherencia siempre es coherente.
Importante. Queremos que el historial sea auditable, especialmente en empresas con regulación sanitaria. Los planes son inmutables una vez asignados. Si el nutricionista quiere cambiar algo, crea una nueva versión y reasigna.
⚠ ADR generado: Esta decisión es difícil de revertir, no es obvia, y tiene alternativas reales (mutación in-place). Se documenta como ADR-0001.
04
Concepto crítico — ¿Qué es exactamente la "Adherencia"?
El plan dice "porcentaje de comidas registradas vs. planificadas". Pero hay dos cálculos posibles: (a) tasa de registro — simplemente cuántas comidas anotó el Member, o (b) tasa de conformidad nutricional — qué tan cercano estuvo lo registrado a los macros objetivo. ¿Cuál es "adherencia" en vuestro dominio?
Recomiendo: Separar en dos métricas distintas: LoggingRate (cuántas comidas se registraron) y NutritionalAdherence (cuán ajustadas fueron a los objetivos). Las alertas de 3 días sin registrar disparan sobre LoggingRate, no sobre NutritionalAdherence.
Gran punto. En v1.0 solo medimos registro (si el empleado usa la app). La conformidad nutricional es para v2.1. Entonces la alerta de los 3 días es sobre LoggingRate, y guardamos los datos nutricionales para calcular NutritionalAdherence más adelante.
✓ Términos resueltos: "Adherencia" dividida en LoggingRate (porcentaje de comidas del plan que el Member registró) y NutritionalAdherence (proximidad a los macros objetivo, en scope v2.1). Las alertas del plan original apuntan exclusivamente a LoggingRate.
05
Decisión arquitectónica — Cálculo de LoggingRate: tiempo real vs. batch
Las alertas se disparan si el Member lleva "3+ días sin registrar". Para saber esto necesitas el LoggingRate actualizado. ¿Lo calculas en tiempo real cada vez que un Member registra (o no registra) una comida? ¿O en batch nocturno? Tiempo real es más complejo y costoso; batch es más simple pero la alerta puede llegar con hasta 24h de retraso.
Recomiendo: Batch nocturno para la v1.0. Las alertas de bienestar no son tiempo-críticas (nadie muere si llegan 12h tarde). Tiempo real agrega complejidad de jobs distribuidos que no se justifica ahora. Documentar este trade-off para que no se "arregle" en 6 meses.
De acuerdo. Batch nocturno para v1.0. Si en el futuro queremos notificaciones instantáneas, reevaluamos. Pero ahora no lo necesitamos.
⚠ ADR generado: La elección entre tiempo real y batch es difícil de revertir (implica refactorizar el pipeline de cálculo), no es obvia para un ingeniero nuevo, y tiene alternativas reales. Se documenta como ADR-0002.
06
Ciclo de vida — Member que cambia de Organization
El plan dice que un Member puede "cambiar de empresa". ¿Esto ocurre dentro de NutriTrack (una empresa le da de baja y otra le da de alta) o es literalmente la misma entidad Member que se transfiere? Si un Member tiene historial de adherencia en Empresa A, ¿lo ve la Empresa B? ¿Lo sigue viendo la Empresa A después de que se va?
Recomiendo: Un Member es siempre propiedad de una Organization. Si alguien cambia de empresa, se da de baja en la antigua y se crea un nuevo Member en la nueva. El historial queda en la Organization original (el Member anterior queda "archivado", no borrado). Nunca se transfieren datos entre Organizations.
Correcto. No queremos que el historial médico/nutricional de un empleado fluya entre empresas. Cada Member pertenece a exactamente una Organization en todo momento. Si cambia de empresa, es un Member diferente con nuevo historial.
Implicación de privacidad: La Organization nunca accede al historial de un Member archivado, y la nueva Organization empieza con historial limpio. Esto simplifica también el cumplimiento GDPR (cada Organization gestiona el borrado de sus propios Members).
✓ Regla de dominio capturada: Un Member tiene relación exclusiva (1:1) con su Organization. El cambio de empresa no transfiere datos; genera un nuevo Member en la Organization de destino.
07
Límites del dashboard — "Datos agregados" ¿qué significa?
El plan dice que el dashboard corporativo muestra "métricas agregadas por departamento sin datos individuales". Escenario concreto: si un departamento tiene 2 Members, la tasa de adherencia del departamento revela esencialmente los datos individuales. ¿Hay un umbral mínimo de Members para mostrar agregados?
Recomiendo: Aplicar un umbral de anonimato: si el grupo tiene menos de N Members (sugerido: 5), no mostrar métrica, mostrar "datos insuficientes". Es el mismo principio que aplican encuestas de clima laboral.
Buen punto que no habíamos considerado. Ponemos umbral de 5 Members mínimo para mostrar métrica de departamento. Por debajo de 5, el HRViewer ve "grupo pequeño — dato no disponible".
✓ Regla de dominio capturada: El AggregatedDashboard requiere un mínimo de 5 Members activos por agrupación para mostrar métricas. Grupos menores muestran "dato no disponible" para proteger la privacidad individual.
Resumen ejecutivo de la sesión
El plan original tenía 3 inconsistencias críticas de terminología (Account, Admin, Adherencia) que habrían generado confusión en implementación y posibles bugs de control de acceso. El interrogatorio resolvió todas antes de escribir una línea de código.
Antes de la sesión
- ✗ "Account" = empresa Y empleado
- ✗ "Admin" = nutricionista Y RRHH
- ✗ "Adherencia" = 1 métrica vaga
- ✗ Planes mutables (historial roto)
- ✗ Sin umbral de privacidad
Después de la sesión
- ✓ Organization + Member (distintos)
- ✓ WellnessManager + HRViewer
- ✓ LoggingRate + NutritionalAdherence
- ✓ MealPlan inmutable por diseño
- ✓ Umbral 5 Members para anonimato