Cuando el proyecto crece, aparece la pregunta
Todo proyecto de transformación de datos empieza chico. Un repositorio, un equipo, un conjunto de modelos que se conocen entre sí. Pero cuando el proyecto escala, cuando se suman dominios de negocio, cuando hay más gente tocando el mismo código, aparece una pregunta inevitable: ¿tiene sentido seguir con todo en un solo repositorio?
La respuesta intuitiva es partir. Marketing por un lado, finanzas por otro, producto en su propio repo. Cada equipo con su espacio, su ritmo de deploy, su autonomía. Suena razonable.
El problema es que esa partición choca con algo que en modelado dimensional se llama dimensiones conformadas.
Qué son las dimensiones conformadas y por qué importan acá
Una dimensión conformada es una dimensión que se comparte entre múltiples procesos de negocio. La dimensión de clientes, por ejemplo, la usa marketing para segmentar campañas, finanzas para calcular revenue por cliente, y producto para medir adopción de features.
Si cada dominio tiene su propio repositorio de transformación, ¿dónde vive esa dimensión de clientes? Hay tres opciones, y ninguna es mejor que la otra.
La primera es duplicarla. Cada repo tiene su propia versión de la dimensión. El problema es obvio: si la lógica de cómo se define un cliente activo cambia, hay que cambiarla en tres lugares. Y si no se cambia en los tres, los números de marketing, finanzas y producto dejan de cerrar.
La segunda es que un repo sea el "dueño" y los demás consuman. Pero eso genera dependencias cruzadas entre repositorios. El repo de marketing depende del de finanzas para la dimensión de clientes. Eso complica el deploy, complica el testing, y complica saber qué se rompe cuando alguien cambia algo.
La tercera es tener un repo central solo para dimensiones conformadas. Pero entonces tenés un repo que todos necesitan, que todos tocan, y que se convierte en cuello de botella. Volvés a tener un monorepo, solo que ahora está partido en pedazos que dependen unos de otros.
El monorepo como consecuencia, no como dogma
Cuando mirás el problema desde las dimensiones conformadas, el monorepo deja de ser una preferencia estética y se convierte en una consecuencia del modelo de datos.
Si tu modelo dimensional tiene dimensiones que se comparten entre dominios, y querés que esas dimensiones tengan una sola definición, terminás con un repositorio que contiene todo. No porque sea más lindo, sino porque es la forma más simple de garantizar que la dimensión de clientes sea la misma para todos.
Eso no significa que el monorepo no tenga problemas. Los tiene. Cuando el proyecto crece, el repositorio se vuelve pesado. Los tiempos de CI aumentan. La coordinación entre equipos se complica. Hay más gente tocando el mismo código, más conflictos de merge, más riesgo de que un cambio en un dominio rompa otro.
Pero esos problemas son de escala y coordinación. Se pueden mitigar con estructura interna (carpetas por dominio, ownership claro, tests por área). Los problemas del multi-repo con dimensiones conformadas son de consistencia de datos. Y esos son más difíciles de resolver.
Cuándo tiene sentido partir
Hay casos donde partir en múltiples repositorios sí tiene sentido.
El primero es cuando los dominios son realmente independientes. Si marketing y finanzas no comparten ninguna dimensión, si cada uno tiene su propio modelo de datos sin puntos de contacto, entonces no hay dimensiones conformadas que proteger. Cada repo puede vivir su vida.
El segundo es cuando la organización ya tiene un mecanismo robusto para compartir definiciones entre repositorios. Algunas empresas tienen catálogos de datos centralizados, contratos de datos formales, o capas de abstracción que permiten que un repo consuma definiciones de otro sin acoplarse al código. Si eso existe y funciona, el multi-repo es viable.
El tercero es cuando el costo de coordinación del monorepo supera el costo de inconsistencia del multi-repo. En organizaciones muy grandes, con muchos equipos y mucha autonomía, a veces es preferible aceptar cierta inconsistencia entre dominios a cambio de velocidad de desarrollo. Pero eso es una decisión consciente, no un accidente.
El dilema real
La decisión entre monorepo y multi-repo en transformación no es técnica. Es de gobierno.
Si tu organización prioriza consistencia entre dominios, si las métricas de marketing tienen que cerrar con las de finanzas, si la dimensión de clientes tiene que ser la misma para todos, entonces el monorepo es el camino más directo. No el único, pero sí el más simple.
Si tu organización prioriza autonomía de equipos, si cada dominio puede definir sus propias entidades sin coordinarse con otros, si la consistencia entre áreas es un nice-to-have y no un requisito, entonces el multi-repo puede funcionar.
Lo que no funciona es partir el repositorio para reducir complejidad percibida y después descubrir que las dimensiones conformadas generan dependencias que nadie anticipó. Eso no reduce complejidad. La esconde hasta que explota.
En resumen
Partir un proyecto de transformación en múltiples repositorios reduce el tamaño de cada repo, pero no elimina las dependencias entre dominios. Si hay dimensiones conformadas que se comparten, esas dependencias siguen existiendo. La pregunta es si las hacés explícitas en un monorepo o las dejás implícitas en dependencias cruzadas entre repos.
El monorepo no es la única respuesta, pero es la respuesta más simple cuando el modelo de datos tiene dimensiones compartidas. Partir tiene sentido cuando los dominios son realmente independientes, cuando hay mecanismos robustos para compartir definiciones, o cuando la organización acepta conscientemente cierta inconsistencia a cambio de autonomía.
La decisión es de gobierno, no de herramientas. Y como toda decisión de gobierno, tiene consecuencias que se pagan después.