Nakire TPS: software distribuido para operaciones industriales en tiempo real.

Resumen ejecutivo

Nakire TPS conecta la operación física de un almacén con el software que la coordina. El sistema une 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.

Se desarrolló en dos fases: un MVP entre abril y julio de 2025 y una segunda fase de septiembre de 2025 a junio de 2026.

De dónde viene la arquitectura

Nakire TPS es un desarrollo propio. Lo que viene de atrás es la forma de pensar el sistema, no su código: el primer motor que escribí fue el buscador de Basetis, con consultas entre corchetes —AND, OR, NOT, NOR— y un validador por expresiones regulares. En LoveISDIN llevé el frontend y me encontré por primera vez con DDD y hexagonal en el backend; la parte visual, que hasta entonces crecía en componentes enormes, pasó a Atomic Design con una capa previa: partículas, átomos, moléculas, organismos, layouts y páginas.

En Bodega Digital llevé por primera vez esa arquitectura de backend al frontend, dentro de un monolito: un solo despliegue y límites de dominio en el código. Nakire TPS lleva la idea a microservicios: cada familia de dispositivos con su propio servicio, un core de dominio que conoce las tareas y reglas iguales en todos los módulos.

Contexto industrial

En un almacén automatizado, 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é.

Cada almacén llega con 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

• 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

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 del almacén.

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.

Cada módulo tenía su API, su backoffice y su frontend, y compartía un DDD core con el resto: las reglas de negocio vivían en el dominio del módulo. El control de acceso por rol atravesaba el sistema entero, de modo que el mismo operador veía lo que le tocaba en cualquier módulo.

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. La persistencia acompaña esa división: time-series para métricas, PostgreSQL y Redis para transacciones.

Reglas del sistema

Un caso de uso puede emitir los eventos que decida el negocio, pero cada evento lo consume un solo caso de uso. La regla parece pequeña y cambia el sistema entero: deja una traza limpia de quién hizo qué y un único punto de error, siempre en el mismo sitio, por el que pasan todos los eventos.

Esa trazabilidad se pensó para la operación: cuando una tarea no avanza, hay un sitio donde mirar. Con la misma lógica, el tiempo real se declara en el caso de uso.

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 el almacén, y no una pantalla genérica con todas las posibilidades.

Además del WebSocket, el sistema usaba SSE para las actualizaciones delta: el caso de uso decide si un cambio de estado —una tarea que pasa de PENDING a IN_PROGRESS— merece un envío, lo publica en el bus y el handler lo reparte entre los listeners suscritos a esa tarea. La suscripción la declara el cliente al abrir la tarea.

CI/CD y despliegue

La plataforma se despliega con Docker y Kubernetes 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 el almacén.

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.
• La documentación y el vocabulario compartido con fabricantes son parte de la ingeniería, no un trámite.