3.8 KiB
3.8 KiB
ADR-003: Provisión inicial de datos al alta (familia y niño)
| Metadata | Valor |
|---|---|
| Estado | Aceptado (implementado) |
| Fecha | 2026-07-12 |
| Autor(es) | Jaume Garriga Maestre |
| Supersede | — |
Contexto
Una familia recién registrada empezaba con la app vacía: había que crear a mano todos los materiales, actividades y rutinas. El objetivo es que cualquier familia arranque con un dataset inicial útil: material escolar típico y rutinas de tarde apropiadas a la edad de cada niño (tramos 8-9 / 10-11 / 12-14, tomados de la literatura de desarrollo de autonomía en TDAH), sin impedir personalizarlo después.
Restricción estructural clave: los datos cuelgan de family_id y child_id, que
son datos de runtime (se crean al registrarse), no de esquema.
Opciones Consideradas
Opción A: INSERTs en un changeset Liquibase
| Pros | Contras |
|---|---|
| Versionado junto al esquema | Inviable: Liquibase corre ANTES que cualquier ApplicationRunner; en la migración no existe aún ninguna familia a la que apuntar (FK NOT NULL) |
Opción B: Ampliar el DataSeeder
| Pros | Contras |
|---|---|
| Sencillo | Solo actúa con BD vacía (familia demo); las familias reales que se registren después no reciben nada |
Opción C: Servicio de provisión invocado en el alta (elegida)
| Pros | Contras |
|---|---|
| Se ejecuta exactamente cuando existen los datos padre (familia/niño) | Lógica de negocio adicional que testear |
| La edad del niño está disponible en su alta → tramo correcto | El catálogo posterior al alta no se "resincroniza" (decisión consciente) |
| Transaccional con el registro: o todo o nada |
Decisión
Opción C. InitialDatasetService con dos operaciones:
provisionFamily(family)— enAuthService.register(): catálogo de materiales escolares típicos (9) + catálogo completo de rutinas (14).provisionChildRoutines(child)— enChildService.create(): asigna a L-V las rutinas del catálogo cuyominAge≤ edad del niño (acumulativo: base 0 / organización 10 / corresponsabilidad 12).
El DataSeeder demo delega en el mismo servicio (una sola fuente de verdad) y
solo añade sus extras (actividades del horario, premios, eventos).
Trade-offs
Optimizamos para:
- Time-to-value de la familia: la app es útil desde el minuto uno.
- Adecuación evolutiva: las responsabilidades crecen con la edad del niño.
Sacrificamos:
- Sincronización posterior: si la familia borra rutinas del catálogo, los niños creados después reciben solo las que sigan existiendo (se busca por etiqueta ES). Aceptable: respeta la personalización de la familia.
- Contenido opinado: el set inicial es una propuesta pedagógica, no neutra; mitigado porque todo es editable desde el panel.
Asunciones que podrían invalidar esta decisión:
- Si el dataset inicial necesitara variar por idioma/región o ser configurable por el admin, reconsiderar moverlo a datos (tabla de plantillas) en vez de código.
Consecuencias
- (+) El registro deja a la familia lista para usar; el alta de un niño de 13 años le pone 14 rutinas x 5 días sin tocar nada.
- (−) El seed vive en código Java (constantes): cambiarlo requiere release. Asumido para v1 doméstica.
Criterios de Éxito
- Registro → 9 materiales + 14 rutinas de catálogo (test verde).
- Niño de 8 → 25 asignaciones; niño de 13 → 70 (test verde).
- Demo y familias reales comparten la misma provisión (DataSeederIT verde).
Referencias
backend/.../service/InitialDatasetService.java(+ test)backend/.../security/AuthService.java,service/ChildService.java,bootstrap/DataSeeder.java- ADR-002 (el catálogo reutilizable es prerrequisito de esta provisión)