CAPÍTULO 11 · Volver a empezar con una base mejor
La base que nos llevamos al siguiente proyecto
Al comienzo queríamos elegir una tecnología y construir algo que el equipo pudiera repetir. Después del recorrido, esa base ya no es solo una carpeta que arranca. config permite reconocer entornos; las apps delimitan responsabilidades; queries y commands explican intenciones; los servicios reúnen reglas; repoGenerico y UTIL_LIB conservan comportamientos que no queremos reescribir.
Las mismas decisiones se conectan hacia afuera. La interfaz comparte capacidades con el backend, la identidad tiene un flujo definido y la base de datos limita sus cuentas. La entrega manual produce un artefacto identificable, y la operación aporta información para mantenerlo, corregirlo y recuperarlo. Ninguna pieza resuelve todo por sí sola: su valor aparece en las relaciones que aprendimos a seguir.
Replicar el proyecto significa llevar ese conocimiento al nuevo contexto. Algunas convenciones podrán mantenerse; otras necesitarán cambiar porque habrá usuarios, datos o condiciones distintas. Lo importante es poder explicar por qué se conserva cada parte y qué evidencia hará necesaria otra decisión. Copiar sin comprender volvería a dejarnos en el punto de partida.
La historia termina con una capacidad del equipo: comenzar de nuevo con menos incertidumbre y con preguntas mejores. Cuando llegue la próxima necesidad, ya no tendremos únicamente código disponible. Tendremos una manera compartida de construir, revisar y aprender de lo que ponemos en funcionamiento.
Leer esta parte dentro del relato completo →DEL RELATO A LA PRÁCTICA
Vamos a desarrollar esta decisión con su mapa, explicación, código y ejercicio.
MIRA · CONECTA · COMPRENDE
El taller completo de SensorHub
Las flechas muestran responsabilidades relacionadas; no representan un orden obligatorio de ejecución.
Selecciona una pieza para destacar su responsabilidad.
Leer la explicación del mapa
- Experiencia web. Consulta y acciones
- Casos de uso. Aplican reglas y capacidades
- Datos. Catálogo e históricos
- Telemetría. Ingesta, eventos y alarmas
01 / EL PROBLEMA
¿Para qué sirve?
Aprender patrones aislados no basta. El proyecto final conecta persistencia, casos de uso, contrato HTTP y UI en una operación verificable.
02 / COMPRENDER
El concepto, explicado
La funcionalidad final registra sensores, recibe lecturas idempotentes, consulta históricos y produce alarmas con rearme. Las capacidades se aplican en el backend y se reflejan en la UI.
El criterio de éxito es comportamiento observable, no número de carpetas. Debes poder explicar qué dato llega, dónde se valida, qué se guarda y qué sucede ante un reintento.
03 / CONSTRUIR
Implementación paso a paso
- Implementa catálogo y serializadores.
- Agrega Query paginada y Command de registro.
- Construye ingesta con identidad técnica y clave única.
- Integra histórico, alarma, exportación y pruebas.
04 / APLICAR
Ejemplo en SensorHub
# Secuencia del caso de uso:
# HTTP → autenticador técnico → permiso de sensor
# → ReadingInput → servicio store_reading
# → Reading + snapshot de calibración + outbox
# → respuesta 201 si nueva, 200 si repetida
#
# Consulta:
# usuario → permiso → queryset autorizado → rango
# → paginación/decimación → serializer → JSON
#
# UI:
# controlador → API → estado → vistaCómo leer el ejemplo
- Cada flecha es un contrato que puedes probar.
- Los efectos externos se entregan después de confirmar los datos.
- Una academia pública puede explicar estos mecanismos sin imponer login a sus lectores.
Error habitual
No agregues todas las abstracciones a la primera funcionalidad. Empieza vertical, mide repetición y extrae solo lo que tenga una responsabilidad estable.
05 / PRACTICAR
Tu turno
Entrega SensorHub con README, migraciones y pruebas que otra persona pueda ejecutar.
Ver solución orientativa
La entrega incluye comandos reproducibles, payload de ejemplo, matriz de capacidades, tratamiento de errores e instrucciones de despliegue. Demuestra una lectura repetida sin duplicado y una denegación sin escritura.
06 / VERIFICAR
Cómo sabes que funciona
- El proyecto arranca desde un checkout limpio.
- La funcionalidad cumple reglas de integridad, acceso y repetición.
- Puedes justificar cada capa con una necesidad concreta.
La próxima necesidad abre otro comienzo
La base queda lista para revisarla, adaptarla y llevar lo aprendido a otro proyecto.
Volver a leer el recorrido →