CAPÍTULO 1 · Un equipo, una base común
Antes de tener un proyecto, teníamos una responsabilidad
Todo comenzó en un área donde sabíamos resolver problemas de ingeniería, pero no contábamos con un equipo dedicado al desarrollo de software. Había conocimientos de electrónica, mecánica, química y otras especialidades. Yo venía de la electrónica y había participado en proyectos que me habían acercado a la programación. Esa experiencia me permitía empezar, aunque el desafío ya no consistía en hacer funcionar una solución para mí: necesitábamos construir algo que otras personas del equipo pudieran comprender y continuar.
Elegimos Python porque sus bases resultaban familiares para el grupo. Django nos ofrecía una estructura sobre la cual organizar una aplicación web, pero escoger el framework no resolvía las exigencias de los clientes. La seguridad, los datos, la infraestructura y el mantenimiento iban a acompañarnos durante toda la vida del proyecto. La meta era preparar una base que pudiéramos repetir, sin empezar de cero cada vez.
Para recorrer esa experiencia construiremos SensorHub, una plataforma didáctica de estaciones, sensores y mediciones. Antes de abrir la terminal, necesitamos reconocer quién consultará los datos, quién podrá cambiar una configuración y qué información no puede perderse. Esas preguntas nos dan un primer alcance. Ahora podemos convertir la idea en un proyecto que arranque en el computador.
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
Del plano al taller
Las flechas resumen el recorrido conceptual. Los controles y dependencias se detallan debajo.
Selecciona una pieza para destacar su responsabilidad.
Leer la explicación del mapa
- Requisitos. Define problema y restricciones
- Módulos. Separa responsabilidades
- Modelo. Representa reglas del dominio
- Criterios. Comprueba el comportamiento
01 / EL PROBLEMA
¿Para qué sirve?
Una plataforma crece mal cuando cada pantalla inventa sus reglas. Un diseño breve permite decidir qué debe permanecer consistente antes de crear tablas o endpoints.
02 / COMPRENDER
El concepto, explicado
Este recorrido parte de la experiencia de un ingeniero electrónico que había participado en proyectos de software y asumió la construcción de una base Django para un equipo de otras especialidades. SensorHub es el ejemplo didáctico que usaremos para explicar esas decisiones; la secuencia organiza el aprendizaje y no pretende fechar los acontecimientos reales.
Construiremos SensorHub: estaciones con sensores que envían mediciones de temperatura. Un operador consulta históricos, un supervisor define umbrales y un administrador gestiona el catálogo.
Una entidad representa algo con identidad: estación, sensor o lectura. Un caso de uso expresa una intención: registrar sensor, consultar histórico o procesar una lectura. Una regla pertenece al negocio: una lectura debe tener fecha y un sensor registrado.
Comienza con un monolito modular. Todas las apps comparten proceso y base de datos, pero cada una mantiene una responsabilidad. Puedes extraer servicios después si existe una necesidad concreta de escala o independencia.
03 / CONSTRUIR
Implementación paso a paso
- Escribe tres casos de uso con entrada y resultado.
- Distingue estaciones, sensores y mediciones.
- Define las reglas que deben cumplirse incluso sin interfaz.
- Asigna responsables: catálogo, telemetría y cuentas.
04 / APLICAR
Ejemplo en SensorHub
SensorHub
├── catalogo/ # estaciones y sensores
├── telemetria/ # ingesta, históricos y alarmas
├── cuentas/ # identidad y permisos del ejemplo
├── repoGenerico/ # vistas HTTP reutilizables
├── UTIL_LIB/ # cálculos y conversiones
└── config/ # composición y entornosCómo leer el ejemplo
- Las apps expresan áreas del negocio.
- repoGenerico comparte algoritmos HTTP; UTIL_LIB contiene funciones que no necesitan request.
- La academia pública no activa cuentas: ese módulo se enseña para aplicaciones que lo requieren.
Error habitual
Dividir en muchas carpetas no crea límites por sí solo. Si todas importan y cambian todo, la dependencia sigue siendo difícil de mantener.
05 / PRACTICAR
Tu turno
Describe el caso “registrar lectura” con entrada, regla y salida.
Ver solución orientativa
Entrada: código de sensor, fecha, temperatura y clave de evento. Regla: el sensor existe y la fecha es válida. Salida: lectura guardada o error de validación.
06 / VERIFICAR
Cómo sabes que funciona
- Cada caso tiene una responsabilidad principal.
- Las reglas pueden explicarse sin hablar de botones o templates.
CONTINUAR LA EXPERIENCIA
El siguiente paso del recorrido:
Preparar el proyecto y el entorno →Continuar en modo relato