Pensar en la arquitectura de una aplicación completa puede parecer abrumador, pero cuando se parte de un caso real —como una empresa de logística que transporta paquetería del punto A al punto B a nivel internacional— todo cobra sentido. Aquí se plantea un escenario donde administradores, clientes y operadores en puertos interactúan con un mismo sistema, cada uno desde dispositivos y contextos distintos.
¿Cómo funciona el flujo de operación en un puerto?
El proceso comienza cuando un barco llega cargado de containers [0:18]. Los operarios descargan esos contenedores y dentro encuentran cajas individuales. Cada caja tiene un código de barras que el operario escanea con la cámara de su teléfono móvil [0:30].
Una vez escaneado el código, el sistema permite editar el estado del paquete con opciones claras:
- OK: el paquete llegó en perfectas condiciones.
- Daño menor: presenta algún tipo de deterioro parcial.
- Completamente roto: el paquete no es funcional [0:38].
Después de registrar el estado, el operario debe indicar el tipo de transporte utilizado: camión, tren o barco, junto con el nombre y la identificación del vehículo [0:50].
¿Qué papel juega la geolocalización y los datos del dispositivo?
El teléfono del operario utiliza el GPS —la antena de geolocalización— para determinar automáticamente en qué puerto o zona franca se encuentra [1:02]. No importa si es Cartagena, Barranquilla, Sevilla o Barcelona; el sistema captura la ubicación sin intervención manual.
Además, los datos del sistema operativo del teléfono permiten registrar automáticamente la hora y la fecha del evento [1:16]. Esto garantiza trazabilidad completa de cada paquete en cada punto de su recorrido.
¿Qué ven los diferentes usuarios del sistema?
No todos los roles acceden a la misma información. Los administradores, operadores y clientes tienen vistas diferentes [1:22]:
- Los clientes pueden ver todas sus órdenes activas: qué están enviando y hacia dónde.
- Al consultar los detalles de una orden, aparece el registro completo del estatus: en qué momento, en qué puerto estuvo y cuál fue el estado reportado.
- Los ejecutivos de cuenta y administradores acceden desde sus propias máquinas de manera independiente.
¿Por qué pensar primero en la estructura de datos con Excel?
Antes de hablar de bases de datos, backend o interfaces móviles, se lanza un reto fundamental [1:38]: ¿cómo resolverías todo esto usando hojas de cálculo? La pregunta no es trivial. Obliga a pensar en cuáles serían las tablas, las columnas y cómo se relacionarían los datos entre sí.
Este ejercicio es clave porque la estructura de datos es la base de cualquier arquitectura de software. Si logras organizar la información en Excel de manera lógica, ya tienes el primer boceto de tu modelo de datos.
¿Cuáles son las restricciones que debes considerar?
Al diseñar esta estructura, hay que tener en mente condiciones reales del entorno [1:50]:
- El sistema debe funcionar en puertos con datos móviles desde un teléfono.
- El cliente lo consulta desde su computadora.
- Los administradores y ejecutivos de cuenta lo revisan en máquinas individuales y separadas.
- Son sistemas aislados que deben mantenerse sincronizados.
Estas restricciones obligan a pensar en cómo los datos viajan entre dispositivos, cómo se sincronizan y cómo cada rol accede solo a lo que le corresponde. La separación entre dispositivos móviles y de escritorio también anticipa decisiones sobre conectividad, almacenamiento local y comunicación con servidores.
Resolver este problema en Excel antes de escribir una sola línea de código es un ejercicio de modelado de datos que revela la complejidad real del sistema. ¿Ya tienes tu propuesta? Comparte cómo organizarías las tablas y qué columnas usarías.
