7 preguntas para revisar
tu arquitectura
educativa

Una herramienta breve para descubrir si tu ecosistema depende demasiado del course_id y redibujar sus fronteras sin reescribirlo todo. Marca las casillas directamente sobre el documento.

andresmartinezsoto.eu Consultoría Moodle · LTI · Arquitectura EdTech

Antes de crear el siguiente endpoint

La pregunta correcta no es “qué curso sincronizo”

Si llevas años integrando plataformas educativas, la conversación empieza casi siempre con la misma pregunta: ¿cómo sincronizamos los cursos? Es razonable —y suele ser la primera decisión que hipoteca la arquitectura.

El curso es una vista operativa del aprendizaje, no un contrato universal. Este checklist te ayuda a detectar en diez minutos dónde tu integración ha confundido un contenedor con una frontera de negocio.

Cómo usar este checklist

Elige una sola integración de tu ecosistema (LMS ↔ ERP, LMS ↔ herramienta LTI, LMS ↔ analítica…). Recorre las 7 preguntas en orden y marca lo que ya tienes resuelto. Si varias respuestas dependen de “mirar el course_id en Moodle”, tu modelo necesita una frontera más precisa.

¿El “curso” representa una definición estable o una edición concreta?

Definición vs. oferta: la distinción pequeña que evita años de deuda técnica.

El catálogo tiene una entidad reutilizable (título, objetivos, competencias) separada de la instancia impartida.
Crear una nueva convocatoria no obliga a duplicar el contenido pedagógico.
Una misma oferta puede convivir en dos ediciones sin conflicto de identidad.

¿Qué debería sobrevivir cuando esa edición se duplica, restaura o archiva?

El logro y la evidencia tienen una vida útil más larga que el aula virtual.

Las credenciales emitidas conservan su identificador aunque el curso se archive.
Las evidencias de aprendizaje no viven únicamente dentro del LMS.
Una restauración de copia de seguridad no rompe las referencias externas al curso.

¿La integración necesita todo el contexto o solo una parte?

No todo lo que pasa en un curso es relevante para el otro sistema.

Si el objetivo es conceder acceso, se usa una asignación, no una copia del curso.
Si el objetivo es devolver una nota, se actualiza un line item, no el curso completo.
Si el objetivo es analítica, se envían eventos, no el estado agregado del contenedor.

¿Quién es propietario de cada dato y quién puede corregirlo?

Un /sync-course que esconde siete responsabilidades es un anti-patrón.

Existe una matriz clara: qué sistema crea la identidad, la membresía, el resultado, la credencial.
Ningún sistema es “propietario accidental” de datos que pertenecen a otro dominio.
Los conflictos de escritura se resuelven por ownership, no por orden de llegada del cron.

La segunda mitad

Identidad, idempotencia y trazabilidad

¿Los identificadores son canónicos o pertenecen a una instalación concreta?

Muchos fallos de integración atribuidos a las APIs son, en realidad, fallos de identidad.

Existen identificadores de dominio estables, separados de las claves locales de cada sistema.
Hay una tabla de correspondencias explícita entre clave canónica y clave local.
No se usan campos mutables como clave (correo, nombre corto, título visible).

¿Podemos procesar dos veces el mismo mensaje sin duplicar matrículas, notas o certificados?

La idempotencia no es un detalle técnico: es la base de una integración robusta.

Cada operación lleva una clave idempotente y una versión explícita del contrato.
Existe un identificador de correlación que permite reconstruir la cadena completa.
Los procesos de reconciliación están acotados por entidad y periodo, no son copias ciegas.

¿Podemos explicar el estado actual reconstruyendo su trazabilidad?

“¿Por qué este usuario aparece aquí?” debería responderse sin revisar cuatro bases de datos a mano.

Los eventos expresan hechos del dominio (learning.activity.completed), no course.updated.
Cada cambio conserva origen, fecha efectiva y responsable del dato.
No hace falta una sincronización nocturna “por seguridad” para corregir inconsistencias.

Resultado

Si has marcado 18 o más casillas, tu arquitectura ya distingue contexto, membresía, actividad, evidencia y credencial. Si te faltan varias, el siguiente paso no es reescribir el ecosistema: elige un solo contrato (membresía, resultado o credencial), dale idempotencia, propiedad y trazabilidad, y avanza por capas.

Siguiente paso

Si tu ecosistema depende de un course_id omnipresente, podemos redibujar sus fronteras sin detener la operación.

Trabajo con instituciones y proveedores EdTech sobre Moodle, LTI 1.3, xAPI, OneRoster y arquitecturas de integración. La migración se hace por capas, midiendo impacto y sin pagar toda la deuda técnica a la vez.

→Auditoría rápida de tu ecosistema actual (1 sesión).
→Definición de contratos por capacidad y matriz de ownership.
→Diseño de la primera migración modular (membresía, AGS o credenciales).
→Acompañamiento técnico durante la implantación.

Reservar una conversación Leer el artículo completo

— Andrés Martínez Soto
Consultor EdTech · Arquitecto de software

7 preguntas para revisar tu arquitectura educativa