Era una de esas conversaciones que parecen ordinarias hasta que, de repente, no lo son.
Mi colega llevaba poco tiempo en el equipo — el suficiente para ver el problema con claridad, sin las capas que el tiempo inevitablemente añade. Se recostó un poco en su silla, cruzó los brazos, y con la seguridad tranquila de alguien que acaba de encontrar la respuesta obvia, dijo: “¿Por qué llevar la modularización tan lejos? No somos un ecosistema como el de Uber.”
Hubo un silencio breve. De esos que no son incómodos, sino pensativos.
Porque tenía razón. Y yo lo sabía.
No era la primera vez que escuchaba ese argumento. Años atrás, al inicio de mi carrera, yo mismo lo usé.
Descarté esfuerzos de modularización en un proyecto convencido de que éramos pragmáticos, no sobre-ingenieros. Lo que vino después no fue elegante: alta cohesión entre partes del sistema que nunca debieron tocarse, conflictos que tomaban días en resolverse, lanzamientos que se arrastraban, time to market que se alargaba hasta volverse una fuente constante de estrés para el equipo. No fue un fracaso dramático. Fue algo peor — fue lento, desgastante, y completamente evitable.
Por eso el comentario de mi colega me detuvo. Porque sonaba exactamente como yo, años atrás.
Si tomas esa afirmación de forma aislada — con el zoom puesto en ese fragmento — la lógica es sólida. Los grandes sistemas distribuidos y altamente modularizados existen porque surgieron de necesidades reales de escala. Replicar esos patrones sin esa necesidad puede parecer over-engineering: más complejidad, más indirección, más superficie para que algo salga mal. Hay incluso un principio que lo respalda directamente: YAGNI — You Aren’t Gonna Need It. Uno de los más respetados en ingeniería de software, y con razón. La complejidad que no resuelve un problema real es deuda, no arquitectura.
Yo también lo dudé.
Pero hay algo que esa perspectiva, vista desde cerca, no alcanzaba a ver.
La modularización no es solo una decisión de escala. Es una decisión de diseño por fronteras claras. Cuando divides un sistema en módulos bien definidos, cada uno con una responsabilidad delimitada y una interfaz explícita, no estás imitando a Uber. Estás tomando una decisión sobre cómo va a cambiar tu sistema — y quién va a poder cambiarlo sin romper todo lo demás.
Robert C. Martin lo articula en Clean Architecture con una idea que se quedó conmigo: el objetivo de un buen diseño no es prepararse para el tamaño, sino para el cambio. Y eso era exactamente lo que vivíamos. Cada semana llegaban nuevos requerimientos. Flujos completos que se rediseñaban. Prioridades que cambiaban y hacían que lo que hoy era un detalle, mañana se convirtiera en el centro del producto. El sistema no necesitaba modularización porque fuera grande. La necesitaba porque el tipo de cambios que enfrentaba cruzaba constantemente sus fronteras internas — y sin estructura, cada modificación se convertía en una operación de alto riesgo: difícil de aislar, difícil de probar, difícil de entregar con confianza.
Pero — y esto es importante — la modularización mal ejecutada puede crear exactamente el problema que pretende resolver. Si defines mal las fronteras entre módulos — si las trazas en el lugar equivocado, o por las razones equivocadas — el costo de cualquier cambio no desaparece. Solo se mueve. Y refactorizar fronteras que cruzan múltiples módulos es, muchas veces, más costoso que no haberlas puesto. La decisión de modularizar importa. Pero la decisión de dónde trazar las fronteras importa igual o más.
La apreciación inicial de mi colega no estaba equivocada. Estaba incompleta. YAGNI es un principio válido, pero asume que el costo de añadir estructura después es bajo. Cuando el negocio se mueve rápido y los cambios son impredecibles, ese supuesto se rompe. La modularización no era una aspiración técnica. Era una inversión en la velocidad futura del producto.
Esto me dejó con una incomodidad que no sé si alguna vez desaparece del todo:
¿Cuántas veces hemos tomado una decisión convencidos de que era correcta, simplemente porque no habíamos subido suficiente el zoom?
No se trata de experiencia. No se trata de conocer más patrones o haber leído más libros. Se trata de algo más difícil: saber en qué nivel estás parado cuando estás tomando la decisión.
Mi colega no estaba equivocado. Estaba mirando desde un nivel perfectamente válido. Lo que cambiaba al subir un nivel no era la lógica, sino el problema que esa lógica intentaba resolver.
Y eso es lo que hace que la arquitectura sea tan difícil de enseñar — y tan fácil de malentender.
No es un conjunto de reglas. Es un sistema de lentes. Y la pregunta que deberíamos hacernos antes de cada decisión no es “¿es esto correcto?”, sino “¿desde dónde lo estoy evaluando?”
Porque una decisión puede ser brillante en el plano técnico y completamente equivocada en el plano del producto. Puede ser perfecta hoy y obsoleta en tres meses. Puede estar justificada en teoría y ser indefendible en la práctica.
La arquitectura que funciona no es la que cumple con el patrón. Es la que sobrevive al contacto con la realidad.
En el siguiente artículo voy a hablar de algo que me parece incluso más complicado que elegir la arquitectura correcta: cómo leer el contexto antes de elegir. El negocio, el producto, los tiempos, las restricciones. Todo lo que los libros no te dicen — y que sin embargo decide si tu arquitectura va a vivir o morir en producción.
Las opiniones expresadas en este artículo son personales y no representan a ninguna organización.