Bodega Digital: software distribuido para operaciones industriales en tiempo real.

Resumen ejecutivo

Bodega Digital nació para conectar la operación física de un almacén con el software que la coordina. El sistema debía unir personas, aplicaciones y dispositivos industriales —robots, PLC, LEDs, picking, cámaras y sonido— en un mismo flujo de trabajo, con trazabilidad y capacidad de evolucionar almacén a almacén.

La solución se organizó alrededor de dominios y servicios con responsabilidades claras, comunicación orientada a eventos y canales en tiempo real para reflejar el estado de las operaciones. Mi trabajo combinó arquitectura, modelado de dominios, desarrollo de servicios, integración con dispositivos y definición de los flujos de comunicación.

Contexto industrial

En una bodega automatizada, mover un pallet no es una operación aislada: implica una tarea, un dispositivo disponible, un operador que necesita saber qué hacer y un registro de lo que ha ocurrido. El software tiene que coordinar esos actores sin convertirse en un cuello de botella y sin perder de vista quién puede hacer qué.

El punto de partida no era una hoja en blanco: cada almacén tiene su mapa, sus versiones de robot y sus reglas de negocio. El sistema debía absorber esa variación sin multiplicar el código ni depender de un fabricante concreto.

El problema

El reto no consistía únicamente en construir una aplicación, sino en coordinar distintos actores, dispositivos y flujos operativos dentro de un sistema que debía ser trazable, mantenible y capaz de evolucionar.

• Coordinar tareas entre familias de dispositivos muy distintas, cada una con su propio protocolo y su propio ciclo de vida.
• Permitir que la configuración de un almacén —mapa, robots, versiones— cambie sin reescribir el dominio.
• Reflejar el estado de la operación en tiempo real para que las personas puedan actuar sobre lo que está pasando.
• Mantener límites claros entre lo que decide el negocio y lo que decide el hardware.

Restricciones

• Hardware heterogéneo. Carretillas, PLC, LEDs, picking y cámaras no comparten modelo, versión ni protocolo.
• Validación sobre hardware real. Los QA gates del pipeline se ejecutaban sobre dispositivos físicos, no solo sobre mocks.
• Despliegue en cloud bajo VPN. El software vive en cloud y se conecta a la instalación industrial a través de una VPN.
• Fabricantes y documentación. La comunicación técnica y la documentación con fabricantes chinos se hacía en inglés.
• Trazabilidad y roles. Cada operador debía ver y ejecutar solo lo que su rol permitía.

Mi rol

Mi trabajo combinó el diseño de la arquitectura, el modelado de dominios, el desarrollo de servicios, la integración con dispositivos, la definición de los flujos de comunicación y el acompañamiento de las decisiones técnicas. Formé parte de un equipo: lo que sigue distingue lo que diseñé y dirigí de lo que fue trabajo colectivo.

• Diseñé e implementé un sistema orientado a eventos sobre DDD, TDD y microservicios, con un monolito agrupado en frontend, backend, core y un subconjunto de dispositivos.
• Definí el core de agentes que ordena, prioriza y reparte el trabajo entre los dispositivos disponibles.
• Separé cada familia de dispositivo en su propio microservicio, con adaptadores por modelo, versión y protocolo.
• Definí el frontend reactivo por WebSocket y el control de acceso por rol y tipo de operador.
• Acompañé el despliegue en Docker sobre cloud bajo VPN, con CI/CD y QA gates sobre hardware físico real.

Arquitectura

La solución se organizó alrededor de dominios y servicios con responsabilidades claras, comunicación orientada a eventos y canales en tiempo real. El frontend y la API hablan con un core que conoce las tareas; el core no conoce los protocolos de cada dispositivo, solo sus capacidades.

En texto: el frontend se conecta a la API; la API delega en el core de agentes —dictator, ranker y distributor—; el core publica y consume eventos en el bus; cada familia de dispositivo tiene su microservicio con adaptadores por modelo, versión y protocolo; y esos servicios conversan con el hardware real de la bodega.

Dominios y servicios

DDD y TDD se usaron para absorber las reglas de negocio, los mapas y las versiones de robot distintas de cada almacén. La abstracción se hizo por casos de uso, puertos y adaptadores: cambiar una API o un dispositivo no arrastra al dominio.

El core trabaja con tareas de distinto nivel de detalle, desde la tarea que apunta a un dispositivo concreto hasta la que solo expresa la familia y la acción. Esa granularidad permite que el sistema siga coordinando cuando un modelo de robot no está disponible o cuando un almacén incorpora una versión nueva.

Los agentes reparten el trabajo: dictator ordena,ranker prioriza y distributor delega. El objetivo es maximizar la disponibilidad de los dispositivos y minimizar los movimientos necesarios para completar las tareas.

Eventos y comunicación

La comunicación entre servicios es asíncrona y orientada a eventos. El bus de eventos del sistema permite que el core publique lo que ha decidido y que cada servicio reaccione sin que el productor conozca a sus consumidores. Añadir una familia de dispositivos o una nueva capacidad no obliga a tocar el core.

Esa separación también acota el fallo: un servicio de dispositivos que deja de responder no bloquea la coordinación del resto, aunque el sistema deba decidir qué hacer con las tareas que dependían de él.

Integración con hardware

Cada familia de dispositivo —carretilla, PLC, LED, picking, cámara— es su propio microservicio, con adaptadores según modelo, versión y protocolo. El dominio expresa la intención; el adaptador se encarga de traducirla al protocolo concreto.

Ese límite fue la decisión que más veces se pagó sola: un fabricante nuevo o una versión distinta de robot se incorporaba como un adaptador, no como un cambio en las reglas de negocio. También permitió documentar y comunicar las integraciones en inglés con los fabricantes sin mezclar su vocabulario con el del dominio.

Tiempo real y roles

El frontend es reactivo y se comunica por WebSocket: la interfaz refleja el estado de la operación sin que el operador tenga que refrescar. Sobre ese canal se aplica RBAC, de forma que la interfaz se adapta al rol —admin u operador— y al tipo de operador.

La consecuencia práctica es que el operador ve la siguiente acción que le corresponde, con el contexto de lo que está pasando en la bodega, y no una pantalla genérica con todas las posibilidades.

CI/CD y despliegue

La plataforma se despliega con Docker en cloud, bajo VPN hacia la instalación. El pipeline incluye CI/CD y QA gates deterministas sobre hardware físico real: la validación no se quedaba en el entorno de integración, llegaba a los dispositivos que luego operan en la bodega.

Decisiones técnicas

• Core de agentes en vez de una orquestación rígida. Permite priorizar y repartir trabajo según disponibilidad, a cambio de asumir estado e idempotencia en las tareas.
• Un microservicio por familia de dispositivos. Aísla protocolos y versiones, a cambio de más servicios que desplegar y observar.
• Tareas con granularidad variable. El mismo modelo sirve para un dispositivo concreto y para una familia entera, a cambio de un contrato de tarea más rico.
• DDD y TDD para el dominio. Absorben reglas que cambian por almacén, a cambio de un esfuerzo inicial de modelado que se recupera en cada variante.
• QA sobre hardware real. Detecta lo que ningún mock detecta, a cambio de un pipeline más lento y dependiente de dispositivos.

Resultados

El sistema permitió conectar software y operación industrial, mejorar la trazabilidad de los procesos y automatizar interacciones que antes requerían coordinación manual. Los resultados que puedo afirmar son observables, no métricas inventadas:

• Las tareas quedan registradas y asociadas a su dispositivo y a su operador.
• La interfaz refleja el estado de la operación en tiempo real y se adapta al rol de quien la usa.
• Incorporar un modelo o una versión de dispositivo no exige rehacer el dominio.
• El despliegue y la validación están automatizados, incluida la comprobación sobre hardware real.

Aprendizajes

• En sistemas industriales, el hardware marca el ritmo: la arquitectura tiene que asumir que los dispositivos fallan, cambian de versión y no siempre están disponibles.
• Los contratos explícitos entre dominio y dispositivo ahorran más tiempo que cualquier optimización prematura.
• Probar sobre hardware real cambia la conversación con el equipo: los problemas aparecen antes y con nombre propio.
• La documentación y el vocabulario compartido con fabricantes son parte de la ingeniería, no un trámite.