The Professor
Última actualización: 29 de septiembre de 2026. Este documento es el inventario vivo de los requisitos de los proyectos del curso. No habrá solo uno: hoy empieza el hilo conductor, y cada proyecto nuevo abrirá aquí su propia sección con su propio código de identificación.
Cada requisito lleva un ID estable para citarlo en lecciones, ejercicios, soluciones y ADRs. Un requisito no se renumera jamás: si muere, se tacha y se explica; si nace, se añade al final. El número es para nombre, no para orden.
Convención
| Pieza | Regla |
|---|---|
| ID | RF-XX-nn (funcional) · RNF-XX-nn (no funcional) — XX es el código del proyecto |
| Prioridad | Must (sin esto el proyecto no existe) · Should (importante, negociable a corto plazo) |
| Estado | Activo (vigente) · Satisfecho → Lección NN (implementado y demostrado) · Deprecado (tachado, con motivo) |
| Fuente | La lección o decisión que lo introdujo — trazable en ambos sentidos |
La prioridad sigue MoSCoW en su versión honesta: lo que no es Must, no bloquea la entrega, pero también se escribe para no vivir en la cabeza de nadie.
TicketFlow — plataforma de venta de entradas (TF)
API para eventos con aforo limitado: catálogo, reservas de asientos con concurrencia real, cola de compra con Celery, webhooks de pasarela de pago, caché de disponibilidad, idempotencia de pagos, roles y despliegue con Docker. Elegido el 2026-09-28; modelado en la [Lección 00b](/lessons/00b-ticketflow-initial-modeling/lesson/).
Requisitos funcionales
| ID | Requisito | Prioridad | Introducido en | Estado |
|---|---|---|---|---|
| RF-TF-01 | El sistema mantiene un catálogo de eventos con aforo y asientos numerados. | Must | [00b](/lessons/00b-ticketflow-initial-modeling/lesson/) | Activo |
| RF-TF-02 | Un usuario reserva asientos concretos y recibe una reserva con plazo de pago; si el plazo vence, los asientos vuelven a estar disponibles. | Must | [00b](/lessons/00b-ticketflow-initial-modeling/lesson/) | Activo |
| RF-TF-03 | El pago de una reserva confirmada es único e idempotente: la pasarela no puede cobrar dos veces (invariante I3). | Must | [00b](/lessons/00b-ticketflow-initial-modeling/lesson/) | Activo |
| RF-TF-04 | La pasarela de pago notifica el resultado por webhook firmado, con reintentos y verificación de firma. | Must | [17 · Webhooks](/lessons/17-webhooks/lesson/) | Activo |
| RF-TF-05 | Los roles (comprador, organizador, staff) limitan qué puede hacer cada usuario. | Should | [21 · Autorización](/lessons/21-authorization/lesson/) | Activo |
| RF-TF-06 | Las tareas lentas —expiración de reservas, correos de confirmación— corren en cola con Celery, no en el ciclo request/response. | Should | [29 · Colas](/lessons/29-queues-celery/lesson/) | Activo |
| RF-TF-07 | La disponibilidad de un evento se sirve desde caché con estrategia de invalidación explícita. | Should | [38 · Caché](/lessons/38-caching-strategies/lesson/) | Activo |
Requisitos no funcionales
| ID | Requisito | Prioridad | Introducido en | Estado |
|---|---|---|---|---|
| RNF-TF-01 | Un asiento no puede estar en dos reservas activas o confirmadas a la vez (invariante I1): lo impide la base de datos con constraints, no "esperemos que no pase". | Must | [00b](/lessons/00b-ticketflow-initial-modeling/lesson/) | Activo |
| RNF-TF-02 | Toda reserva vence sola si nadie paga: expiración automática sin cron humano ni vigilancia manual. | Must | [00b](/lessons/00b-ticketflow-initial-modeling/lesson/) · [29](/lessons/29-queues-celery/lesson/) | Activo |
| RNF-TF-03 | No se pueden reservar asientos de un evento pasado o cancelado (invariante I4). | Must | [00b](/lessons/00b-ticketflow-initial-modeling/lesson/) | Activo |
| RNF-TF-04 | Reservar, confirmar y pagar son operaciones transaccionales con nivel de aislamiento explícito y razonado. | Must | [10 · Transacciones](/lessons/10-transactions/lesson/) | Activo |
| RNF-TF-05 | El rendimiento objetivo se verifica con pruebas de carga (k6) antes de optimizar; no se adivina. | Should | [36 · Pruebas de carga](/lessons/36-load-testing/lesson/) | Activo |
| RNF-TF-06 | Los secretos viven fuera del código y el tratamiento de datos personales cumple el RGPD. | Must | [23 · Secretos y RGPD](/lessons/23-secrets-gdpr/lesson/) | Activo |
Invariantes del dominio (la ley del sistema)
Extraídas en la [Lección 00b](/lessons/00b-ticketflow-initial-modeling/lesson/) — negocio primero, invariantes después, esquema al final. Todo requisito anterior se remonta a una de estas:
- I1 — Dos reservas activas no pueden incluir el mismo asiento. (La más importante: es el dinero y la reputación del negocio.)
- I2 — Una reserva tiene un plazo de expiración; pasada la hora, no es confirmable.
- I3 — Solo se puede pagar una vez una reserva (idempotencia de pago).
- I4 — No se pueden reservar asientos de un evento pasado o cancelado.
Ninguna está satisfecha todavía: el estado Satisfecho → Lección NN se escribe solo cuando TicketFlow lo demuestre con código real, no cuando la teoría lo explique.
Cómo crece este documento
- Requisito nuevo: fila nueva con el ID siguiente del proyecto, al final de su tabla.
- Requisito que muere: ~~tachado~~ con el motivo y la fecha; nunca se borra.
- Requisito satisfecho: el Estado pasa a
Satisfecho → Lección NN, con enlace a la lección
que lo demuestra.
- Proyecto nuevo: sección propia con su código de dos letras y sus tablas. Mientras no exista,
este epígrafe es la prueba de que la estructura ya lo espera.