Flapper
Flapper: descubrir el dominio antes de separar el monolito
El producto no podía parar, y los autores originales ya no estaban. Antes de migrar, fue preciso descubrir qué fronteras aún revelaba la base.
~25% menos tablas en la separación por dominios
O banco legado revela fronteiras; pessoas, autenticação e aeronaves saem gradualmente para contextos com persistência própria.
Contexto
En Flapper, el producto principal era un monolito PHP con más de siete años, poca documentación útil y sin los desarrolladores que lo habían creado. La aplicación sostenía la operación de aviación ejecutiva y no podía interrumpirse para una reescritura.
Restricciones
El código y la base acumulaban reglas y dependencias difíciles de explicar. Los cambios tenían efectos colaterales poco predecibles, y no había especialistas remanentes para confirmar cómo cada parte del sistema debía evolucionar. La migración necesitaba coexistir con el producto en producción.
Problema
Cambiar PHP por otra tecnología no respondería la duda principal: qué reglas pertenecían juntas y qué dependencias podían separarse sin romper la operación. El sistema necesitaba fronteras de dominio antes de servicios nuevos.
Decisión
Usé la base y el código existente como fuente de descubrimiento. Agrupamientos de tablas y relaciones ayudaron a identificar bounded contexts; a partir de ellos, la migración siguió el patrón Strangler:
- extraer un dominio por vez, sin interrumpir el monolito;
- mantener en cada contexto solo la representación local de los datos que necesitaba;
- propagar cambios por eventos en Kafka, en lugar de conectar todos los servicios a la base antigua;
- usar Node.js, NestJS y Go en los primeros módulos, con gRPC, REST o GraphQL según el consumidor;
- documentar la estrategia y los primeros módulos para que el equipo pudiera continuar la transformación.
Alternativa descartada
Reescribir el monolito entero, o mantener servicios nuevos atados a la misma base y a las mismas relaciones compartidas. La primera opción pararía el negocio; la segunda preservaría el acoplamiento que la migración necesitaba reducir.
Resultado
La separación por dominios redujo en aproximadamente el 25% el número de tablas y creó siete bases organizadas por contexto. Los módulos de personas, autenticación y aeronaves fueron los primeros pasos de una transformación planeada para continuar más allá de la entrega inicial.
Limitaciones
El número mide la reducción de tablas en esa separación de dominios, no una ganancia financiera, la migración completa o un resultado de mercado de la empresa. La fecha final de la experiencia tiene divergencia histórica en fuentes antiguas; el período publicado sigue el perfil exportado. Si un dominio aún depende de reglas no mapeadas en el monolito, su extracción debe posponerse o recibir una integración de transición explícita.