La respuesta corta, para la gran mayoría de los proyectos, es no.
Conviene ponerla al principio porque es la que casi nunca se da. Cuando esta pregunta se le hace a un modelo sin contexto, la respuesta tiende a ser una arquitectura distribuida con su bus de eventos y su diagrama de cajas, porque es lo que más abunda en la literatura técnica reciente. Rara vez es una pregunta de vuelta sobre cuántas personas hay en el equipo.
Este árbol existe para dar esa respuesta con fundamento en lugar de por intuición. Son siete preguntas, ninguna técnica, y varias pueden cerrar la decisión por sí solas.
No es si tu código estará bien organizado. Un monolito modular puede tener límites tan claros como un sistema distribuido, y sale bastante más barato.
Lo que se decide es si esos límites cruzan la red: si cada parte se despliega sola, con su base de datos, su ciclo de vida y sus fallos propios.
El error de plantearlo como un problema técnico
Los microservicios nacieron para resolver un cuello de botella organizativo: varios equipos que se bloquean al desplegar, que dependen unos de otros para sacar una funcionalidad y que no pueden avanzar a ritmos distintos.
Todo lo demás que se les atribuye (escalar mejor, ordenar el código, aislar fallos) o se consigue por otras vías más baratas, o llega acompañado de problemas nuevos. Escalar una parte concreta se puede hacer si esa parte lo necesita de verdad; ordenar el código se hace trazando límites, algo que se puede hacer dentro de un solo desplegable y gratis.
Por eso las preguntas que vienen hablan casi todo el tiempo de personas, dinero y tiempo de respuesta, y muy poco de código.
Qué significa que un límite esté claro
La cuarta pregunta pide comprobar si los límites internos existen, y conviene precisar qué se está mirando, porque es el punto donde más se confunde el deseo con la realidad.
Un límite claro cumple tres condiciones, y las tres se verifican en minutos:
- Los datos tienen dueño. Cada tabla pertenece a un módulo y solo ese módulo escribe en ella. Si dos escriben en la misma, no hay dos módulos: hay uno repartido en dos carpetas.
- La conversación pasa por un sitio conocido. Un módulo llama a otro a través de su interfaz pública, no alcanzando sus clases internas ni consultando sus tablas por atajo.
- Se puede contar qué entra y qué sale. Si no puedes enumerar las operaciones que un módulo ofrece a los demás, ese contrato no está definido y no hay nada que convertir en una interfaz de red.
La comprobación práctica es intentar mover un módulo a otra carpeta y ver qué se rompe. Si aparecen referencias desde media aplicación, el límite estaba solo en el nombre del directorio.
Esto importa porque es justo el trabajo que hay que hacer de todas formas. Si acabas dividiendo, tendrás los límites listos; y si no divides, tienes un sistema más ordenado sin haber pagado nada de la complejidad distribuida.
Si la respuesta es sí, no lo hagas de golpe
Las migraciones de una sola vez son las que se quedan a medio camino, con parte del sistema en cada modelo y el doble de complejidad que cualquiera de los dos por separado.
El camino que funciona es gradual, y tiene nombre propio en la literatura de arquitectura: se deja el sistema existente en su sitio y se va sustituyendo por partes, redirigiendo cada trozo de tráfico al servicio nuevo solo cuando ese trozo está terminado y probado.
En la práctica son cuatro pasos por cada pieza que se extrae:
- Trazar el límite dentro del monolito, con su interfaz pública y sus datos propios, sin mover nada todavía.
- Dejarlo funcionando así un tiempo. Si aparecen atajos hacia sus tablas, el límite estaba mal puesto y corregirlo aquí sigue siendo gratis.
- Sacarlo a un servicio, manteniendo la misma interfaz. Lo que cambia es que detrás hay una llamada de red, con sus fallos y sus tiempos de espera.
- Redirigir el tráfico y dejar la ruta antigua disponible hasta confirmar que la nueva se sostiene.
La ventaja de este orden está en el paso dos: si descubres que el límite no aguanta, no desplegaste nada, no montaste infraestructura y no hay nada que revertir. El paso más valioso es el que se puede deshacer sin coste.
Antes de empezar
Responde con lo que es cierto hoy, no con lo que esperas que sea cierto si el proyecto sale bien. Es el error más común al usar este tipo de listas: se responde con el escenario optimista y se termina construyendo para un problema que nunca llega.
Un sistema simple que funciona para veinte usuarios se puede hacer crecer cuando lleguen los mil. Un sistema distribuido construido para mil usuarios que nunca aparecieron no se simplifica: se reescribe.