ADEN OOUX Architecture

Object-Oriented UX - Objects Matrix

Metodología: OOUX (Object-Oriented UX)
Versión: 1.0
Propósito: Inventario completo de objetos, propiedades, acciones y relaciones

Objetos Principales (6)

1. USUARIO (Paciente)

Object: Usuario
Definition: "La persona usando ADEN para monitorear su salud preventivamente"

Properties:
  Core:
    - id: UUID
    - email: string (unique)
    - nombre: string
    - fecha_nacimiento: date
    - sexo_biologico: enum(mujer|hombre|otro)
    - peso: number(kg)
    - altura: number(cm)
    - ciudad: string
    - avatar_url?: string
  
  Health Profile:
    - health_score: number(0-100)
    - biological_age: number(años)
    - estado_ciclo_actual: enum(baseline|execution|closure|analysis)
    - dias_en_ciclo: number
    - ciclos_completados: number
  
  Metadata:
    - created_at: timestamp
    - updated_at: timestamp
    - last_login: timestamp
    - onboarding_completed_at?: timestamp

Actions:
  - create (registro)
  - read_profile (ver perfil)
  - update_profile (editar datos personales)
  - delete_account (baja)
  - archive (inactividad 90+ días)

Relations:
  - has_many: Ciclo (1 activo + N históricos)
  - has_many: Plan (actual + históricos)
  - has_many: CheckIn (diarios, ~90 por ciclo)
  - has_many: Biomarcador (personalizados, ~72)
  - has_many: Alerta (activas + resuelta)
  - has_one: Familia (si es cuidador)

States:
  - active (usando app)
  - pending_onboarding (completó solo registro, falta labs)
  - pending_labs (onboarding completado, esperando exámenes)
  - active_cycle (ciclo en ejecución)
  - archived (inactivo 90+ días)

2. CICLO (90 Días)

Object: Ciclo
Definition: "Período de 90 días de baseline, ejecución, validación y ajuste"

Properties:
  Core:
    - id: UUID
    - usuario_id: UUID (foreign key)
    - numero_ciclo: number (1, 2, 3...)
    - fecha_inicio: date
    - fecha_fin: date
    - dias_transcurridos: number
    - dias_restantes: number
    - fase_actual: enum(baseline|execution|closure|analysis)
  
  Baseline (Día 1-7):
    - labs_iniciales_cargadas: boolean
    - fecha_baseline_completada?: date
  
  Execution (Día 8-89):
    - check_ins_completados: number
    - check_ins_programados: number
    - adherencia_porcentaje: number(0-100)
    - alertas_activas: number
  
  Closure (Día 90):
    - labs_finales_cargados: boolean
    - fecha_closure_programada: date
    - score_inicial: number
    - score_final: number
    - cambio_score: number (delta)
  
  Analysis:
    - reporte_generado: boolean
    - recomendaciones_ajuste: string[]
    - proximo_ciclo_iniciado: boolean

Actions:
  - create (iniciar nuevo ciclo)
  - start_baseline (recolectar datos iniciales)
  - start_execution (día 8)
  - start_closure (día 90)
  - generate_report (análisis)
  - start_next_cycle (automático si hay adhesión)
  - cancel (si usuario lo solicita)

Relations:
  - belongs_to: Usuario
  - has_many: CheckIn (~90)
  - has_many: Biomarcador (snapshot del día 1 y 90)
  - has_many: Alerta (generadas durante ejecución)
  - has_one: Plan (el plan del ciclo)

States:
  - not_started (programado, no comenzado)
  - baseline (días 1-7)
  - execution (días 8-89)
  - closure (día 90)
  - analysis (post-day 90)
  - completed (ciclo cerrado, nuevo iniciado)
  - failed (abandono, < 50% adherencia)

3. PLAN (Recomendaciones Personalizadas)

Object: Plan
Definition: "Recomendaciones personalizadas del engine: suplementos, ejercicio, nutrición"

Properties:
  Core:
    - id: UUID
    - ciclo_id: UUID (foreign key)
    - usuario_id: UUID
    - fecha_generacion: date
    - fecha_proximo_ajuste: date
    - versión: number (ajustes dentro del ciclo)
  
  Recomendaciones:
    - suplementos: Suplemento[] (array de objetos)
    - ejercicio_recomendado: string (e.g., "Cardio 30 min, 3x semana")
    - nutricion_focus: string[] (e.g., ["incrementar proteína", "reducir sodio"])
    - sueño_objetivo: number(horas)
    - estrés_management: string[] (meditación, yoga)
  
  Razonamiento:
    - basado_en_biomarcadores: string[] (cuáles biomarcadores dispararon cada rec)
    - prioridad_cambios: enum(critical|high|medium|low)
    - proyeccion_impacto: number(0-10) (cuánto podría mejorar el score)

Actions:
  - create (generar plan inicial)
  - read_daily (ver plan del día)
  - read_full (ver plan completo del ciclo)
  - update (ajustar si hay nuevos datos)
  - archive (cuando ciclo termina)

Relations:
  - belongs_to: Ciclo
  - belongs_to: Usuario
  - has_many: Suplemento
  - has_many: Ejercicio (snapshot del plan)

States:
  - draft (generándose)
  - active (en uso)
  - updated (ajustado con nuevos datos)
  - completed (ciclo terminó)
  - archived

4. BIOMARCADOR (Medidas Biológicas)

Object: Biomarcador
Definition: "Medida individual de laboratorio (glucosa, colesterol, etc.)"

Properties:
  Core:
    - id: UUID
    - usuario_id: UUID
    - tipo: enum(sangre|hígado|riñones|corazón|inflamación|etc...) [~10 categorías]
    - nombre: string (e.g., "Hemoglobina")
    - codigo_loinc: string (e.g., "718-7") [para interoperabilidad]
  
  Valor Actual:
    - valor: number
    - unidad: string (e.g., "g/dL", "mg/dL")
    - fecha_medicion: date
    - rango_minimo_optimo: number
    - rango_maximo_optimo: number
    - rango_minimo_aceptable: number
    - rango_maximo_aceptable: number
  
  Estado & Tendencia:
    - estado: enum(óptimo|revisar|atención) [3 niveles, NO 4]
    - tendencia: enum(subiendo|estable|bajando)
    - cambio_porcentaje_vs_anterior: number
    - rcv_detectado: boolean (Reference Change Value - cambio real vs variación)
    - dia_ciclo_medido: number
  
  Histórico:
    - valores_ultimos_90_dias: DataPoint[] 
      - [{ fecha: date, valor: number, estado: enum }]
    - promedio_ultimos_30_dias: number
    - peor_valor_en_ciclo: number

Actions:
  - create (nueva medición cargada)
  - read (ver detalle)
  - read_trend (ver gráfico histórico)
  - read_interpretation (ver explicación científica)
  - compare_with_previous_cycle (N-of-1)

Relations:
  - belongs_to: Usuario
  - belongs_to_many: Ciclo (snapshot en día 1 y 90)
  - triggered_by: Alerta (si sale de rango)

States:
  - pending (cargado pero no procesado)
  - processed (analizado por engine)
  - flagged (dispara alerta)
  - trending (monitoreando tendencia)
  - improved (mejoró vs ciclo anterior)
  - declined (empeoró vs ciclo anterior)

5. CHECK-IN (Entrada Diaria)

Object: CheckIn
Definition: "Captura diaria rápida: ¿tomaste suplementos? ¿hiciste ejercicio? ¿cómo te sientes?"

Properties:
  Core:
    - id: UUID
    - usuario_id: UUID
    - ciclo_id: UUID
    - fecha: date
    - hora_completado: timestamp
    - duracion_segundos: number (<2 minutos = ~120s)
  
  Respuestas:
    - suplementos_tomados: boolean
    - ejercicio_hecho: boolean
    - minutos_ejercicio: number
    - calidad_sueño_noche_anterior: enum(muy_malo|malo|regular|bueno|excelente) [1-5]
    - energia_hoy: enum(muy_baja|baja|normal|alta|muy_alta) [1-5]
    - estrés_nivel: enum(muy_alto|alto|medio|bajo|muy_bajo) [1-5]
    - notas_opcionales: string (comentario libre, max 500 chars)
  
  Metadata:
    - streak_dias_consecutivos: number (al completar)
    - es_primer_checkin_ciclo: boolean
    - recordatorio_tipo: enum(push|email|sms) (cómo fue recordado)

Actions:
  - create (completa check-in diario)
  - read (ver histórico)
  - update (editar antes de cierre día)
  - delete (si se equivocó ese día)

Relations:
  - belongs_to: Usuario
  - belongs_to: Ciclo

States:
  - pending (programado, no completado)
  - completed (usuario respondió)
  - late (completado después de 24h)
  - skipped (día saltado sin respuesta)
  - archived (ciclo terminó)

Constraints:
  - Máximo 1 por usuario por día
  - Duración total < 2 minutos
  - Preguntas son opcionales menos las 3 principales

6. ALERTA (Notificación de Cambios)

Object: Alerta
Definition: "Notificación al usuario cuando algo importante cambia o se sale de rango"

Properties:
  Core:
    - id: UUID
    - usuario_id: UUID
    - ciclo_id: UUID
    - tipo: enum(biomarcador_fuera_rango|rcv_detectado|adherencia_baja|cita_proximidad|recomendacion_ajuste)
    - severidad: enum(low|medium|high|critical)
    - título: string (e.g., "Tu colesterol subió")
    - descripción: string (explicación breve)
    - fecha_creacion: timestamp
  
  Trigger:
    - disparo_por: string (e.g., "biomarcador_id=xxx" o "check_in_streak_roto")
    - valor_que_disparo: any
    - umbral_usado: any
  
  Acciones:
    - cta_primaria: enum(ver_detalle|agendar_cita|chat_healthcoach|ignorar)
    - link_destino: string (ruta en app)
  
  Estado:
    - estado: enum(nueva|leida|resuelta|archivada)
    - fecha_lectura?: timestamp
    - fecha_resolucion?: timestamp
  
  Notificación:
    - canales: enum[] (push|email|sms)
    - fecha_enviada: timestamp[]

Actions:
  - create (disparada automáticamente por engine/regla)
  - read (usuario ve la alerta)
  - resolve (usuario toma acción o la descarta)
  - archive (pasó el relevancia)

Relations:
  - belongs_to: Usuario
  - belongs_to: Ciclo
  - relates_to: Biomarcador (si es por valor fuera de rango)
  - relates_to: CheckIn (si es por datos del check-in)

States:
  - new (recién creada)
  - seen (usuario abrió notificación)
  - resolved (acción tomada)
  - ignored (usuario la cerró)
  - archived (pasó tiempo o ciclo terminó)

Priority Rules:
  - critical: mostrar inmediatamente, insistir con notificaciones
  - high: mostrar en dashboard, 1-2 notificaciones
  - medium: mostrar en dashboard, 1 notificación
  - low: solo en historial de alertas

Matriz de Relaciones

USUARIO (1)
   has_many → CICLO (N) [activo + históricos]
                        has_many → CHECKIN (~90 por ciclo)
                        has_one → PLAN (actual + versiones)
                        has_many → ALERTA (durante ejecución)
  
   has_many → BIOMARCADOR (N) [snapshot en día 1 y 90 de cada ciclo]
                        belongs_to → CICLO
                        triggered_by → ALERTA
  
   has_many → ALERTA (N) [todas las alertas históricas]

Actions por Objeto

Data Structure para DB Schema

// Pseudocode para schema de Drizzle ORM

users {
  id: UUID,
  email: string(unique),
  nombre: string,
  fecha_nacimiento: date,
  sexo_biologico: enum,
  peso: number,
  altura: number,
  ciudad: string,
  health_score: number,
  biological_age: number,
  created_at: timestamp,
  updated_at: timestamp
}

ciclos {
  id: UUID,
  usuario_id: UUID → users.id,
  número: int,
  fecha_inicio: date,
  fecha_fin: date,
  fase_actual: enum,
  score_inicial: number,
  score_final: number,
  created_at: timestamp
}

planes {
  id: UUID,
  ciclo_id: UUID → ciclos.id,
  usuario_id: UUID → users.id,
  suplementos_json: JSON,
  ejercicio_text: string,
  created_at: timestamp
}

biomarcadores {
  id: UUID,
  usuario_id: UUID → users.id,
  tipo: string,
  nombre: string,
  valor_actual: number,
  unidad: string,
  estado: enum,
  fecha_medicion: date,
  created_at: timestamp
}

checkins {
  id: UUID,
  usuario_id: UUID → users.id,
  ciclo_id: UUID → ciclos.id,
  fecha: date,
  suplementos: boolean,
  ejercicio: boolean,
  minutos_ejercicio: int,
  energía: int(1-5),
  estrés: int(1-5),
  created_at: timestamp
}

alertas {
  id: UUID,
  usuario_id: UUID → users.id,
  ciclo_id: UUID → ciclos.id,
  tipo: enum,
  severidad: enum,
  título: string,
  descripción: text,
  estado: enum,
  created_at: timestamp,
  resolved_at?: timestamp
}

Conclusiones OOUX

6 objetos principales cubren todo el flujo de usuario
Relaciones 1:N y M:M reflejan complejidad real
Actions son atómicas (no “create plan + suplemento”, sino acciones separadas)
States del objeto definen lógica (no solo UI)
DB schema sigue naturalmente desde objetos

Próximo: jtbd — Motivaciones reales del usuario