Migración strangler¶
AutoCompraMod no nació de cero: es el resultado de consolidar cinco microservicios del autoservicio en un solo backend modular. Esta página cuenta cómo se hizo esa migración sin un "big bang", y por qué importa para entender el estado del repo.
De dónde venimos¶
El autoservicio eran cinco servicios independientes:
| Microservicio original | Se convirtió en el módulo | Rol |
|---|---|---|
TsTicket |
tickets |
Orquestador: la API que ve el POS. |
TsArticulos |
catalogo |
Artículos por EAN/sucursal. |
TsPagos |
pagos |
intent/pay/check/cancel. |
TsPromos |
promos |
Cálculo de promociones. |
TsEnvases |
envases |
Vales y depósitos retornables. |
Cada uno era un deploy, una base, una conexión que la terminal tenía que orquestar.
El patrón strangler¶
La migración siguió el patrón strangler fig (la "higuera estranguladora"): en vez de reescribir todo de golpe, se va migrando de a un módulo por vez, manteniendo lo viejo en producción hasta que lo nuevo lo reemplaza por completo. Lo nuevo "estrangula" gradualmente a lo viejo.
La secuencia fue:
graph LR
PROMOS["promos<br/>(piloto)"] --> CAT["catalogo"] --> ENV["envases"] --> PAG["pagos"] --> TICKETS["tickets<br/>(host)"]promoscomo piloto. El más simple y autocontenido: se migró primero para validar el enfoque (estructura de módulo + guardrail) con bajo riesgo.catalogo,envases,pagos: uno por uno.ticketscomo host final: el orquestador, lo último, porque es el que ata todo.
En cada paso se corría verify(). Si la migración de un módulo introducía un acceso indebido o un ciclo, el build lo cazaba en el acto. Eso es lo que hizo segura la migración incremental: la red de seguridad no era la confianza, era el guardrail.
Los repos viejos quedaron como referencia
Los cinco repositorios originales (TsTicket, TsArticulos, …) se mantuvieron intactos como referencia hasta el corte. La idea es poder comparar comportamiento contra el canónico mientras la migración se estabiliza.
La otra migración: STOMP → REST en la terminal¶
En paralelo a la consolidación del backend, la terminal cambió cómo habla con él. Originalmente TiprePOS se comunicaba por STOMP/WebSocket; migró a REST puro bajo /autocompras/v1.
Ese cutover está documentado en el propio repo de la terminal (MIGRACION_BLOC_REST.md) y se hizo por fases:
| Operación (antes, destino STOMP) | Ahora (REST) |
|---|---|
openTicket |
POST /openTicket |
agregarArticulo |
POST /agregarArticulo |
removeItem |
POST /removeItem |
closeTicket |
POST /closeTicket |
changeStatusTicket |
POST /changeStatus |
validateTicket |
POST /validateTicket |
payTicket |
POST /payTicket |
Suscripción a /topic/status |
Polling adaptativo de /status (60 s / 15 s) |
Consecuencia: STOMP está muerto en el código actual
En el backend de hoy no hay @MessageMapping ni broker STOMP configurado. Quedan vestigios como TerminalSessionService que son sólo histórico y no se usan. En la terminal, las referencias a STOMP en enums y comentarios están en deprecación (la Fase 3 del plan es eliminar StompService y la dependencia stomp_dart_client). Si leés STOMP en el README viejo del POS, ignoralo: la realidad del código es REST. El detalle vive en Comunicación POS ↔ Backend.
Estado actual¶
- Backend consolidado en el monolito modular, con los cinco módulos migrados y el kernel
shared. - Guardrail (
ModularityTests) activo y en CI (GitHub Actions corremvn testcon JDK 21 en cada push/PR). - Terminal migrada a REST; limpieza final de STOMP pendiente.
- Cockpit (
monitoring) construido sobre las APIs públicas de los módulos, sin acoplarse a sus internals.
Para el detalle técnico de cada módulo migrado, seguí en la Referencia técnica → Los módulos.