Cuando una decisión pequeña deja de ser pequeña
Uno de los retos más exigentes en arquitectura de software es tomar decisiones sabiendo que casi nunca tenemos una respuesta perfecta.
Hay decisiones que se ven mucho. Cambiar una base de datos, separar un servicio, mover algo a cloud o rediseñar una parte importante del sistema. Son decisiones visibles, generan conversaciones y suelen recibir una atención proporcional a su impacto.
Por otro lado, tenemos las decisiones que, cuando todo funciona, parece que lo hace por arte de magia. Elegir una forma de comunicar servicios. Introducir una abstracción para ordenar casos de uso. Decidir cómo gestionamos eventos, mensajes, validaciones o dependencias externas. Apoyarnos en una herramienta porque resuelve bien un problema concreto y nos permite avanzar.
La mayoría de estas decisiones pasan desapercibidas y, en el momento de tomarlas, nos parecen razonables. Y seguramente lo son. Muchas veces no les damos demasiadas vueltas porque tampoco tendría sentido cuestionarlo todo. Si algo funciona, está extendido y resuelve un problema real, lo normal es utilizarlo.
El problema es que algunas de esas decisiones, con el tiempo, empiezan a tener más peso del que parecía al principio.
Cuando la conversación deja de ser técnica
En el ecosistema .NET hemos visto ejemplos bastante visibles en los últimos tiempos con herramientas muy conocidas como MediatR, AutoMapper o MassTransit.
No voy a entrar en un debate sobre ellas. Si tienen tanta adopción es porque resuelven problemas reales y aportan valor a muchos equipos.
Lo interesante aparece cuando dejan de ser una herramienta más y empiezan a ocupar una posición central dentro del sistema:
- Aparece en decenas de proyectos.
- Condiciona la forma en la que se implementan los casos de uso.
- Forma parte del lenguaje habitual del equipo.
- Su ausencia obligaría a replantear una parte relevante de la solución.
En ese momento la conversación cambia. Ya no estamos hablando únicamente de una librería. Estamos hablando de una decisión que ha pasado a formar parte de la arquitectura.
Cuando cambiar deja de ser sencillo
Muchas dependencias entran en un proyecto para resolver un problema concreto.
Pero algunas terminan haciendo algo más y el sistema empieza a crecer alrededor de ellas: aparecen nuevas piezas que las utilizan, se convierten en la forma habitual de trabajar y el conocimiento del equipo se construye parcialmente sobre ellas. En muchos casos, incluso terminan formando parte de las entrevistas técnicas o de las expectativas implícitas que tenemos sobre nuevos miembros del equipo.
Por lo que, con mayor o menor conciencia, acaban ocupando una posición central de nuestros proyectos. Y es entonces cuando descubrimos que cambiar ya no es tan sencillo como parecía.
No porque técnicamente sea imposible. Sino porque el coste real rara vez está solo en el código.
También está en el conocimiento acumulado, en las convenciones establecidas, en las decisiones posteriores que se apoyaron sobre aquella decisión inicial y en todo lo que se construyó alrededor.
La dependencia sigue siendo la misma. Lo que ha cambiado es su relevancia dentro del sistema.
El problema no es la dependencia
No creo que la conclusión sea mirar con desconfianza cada paquete que añadimos a un proyecto, ya que sería, sin duda, una conclusión demasiado pobre.
Construir software moderno sin apoyarse en librerías, frameworks y herramientas de terceros no solo es poco realista. También supondría renunciar a una enorme cantidad de conocimiento acumulado.
El problema no es utilizar dependencias. El problema es no ser conscientes de cuáles de ellas están dejando de ser un detalle técnico para convertirse en algo más importante.
Hay decisiones que podríamos revertir en una tarde. Y hay otras que, sin hacer demasiado ruido, terminan condicionando nuestros casos de uso, nuestros flujos, nuestras pruebas, nuestra observabilidad o incluso la forma en la que el equipo piensa el sistema.
Eso no ocurre porque la herramienta sea buena o mala. Ocurre porque el sistema ha crecido alrededor de ella.
La arquitectura también aparece así
Cuando pensamos en arquitectura solemos imaginar reuniones de diseño, diagramas o decisiones que todo el mundo identifica como importantes desde el principio.
Pero muchas veces la arquitectura aparece de otra forma: en decisiones que parecen pequeñas, en herramientas que resuelven un problema concreto, en abstracciones que simplifican una parte del desarrollo. También en elecciones que, en el momento de tomarlas, parecen tener un alcance limitado.
La mayoría seguirán siendo exactamente eso. Pero otras terminarán ocupando un lugar mucho más importante del que parecía cuando llegaron al proyecto.
Y quizá ahí está la reflexión interesante.
Porque muchas veces la arquitectura no cambia cuando añadimos una nueva pieza al sistema. Cambia cuando el sistema empieza a crecer alrededor de ella.
No siempre podremos anticipar cuáles acabarán teniendo ese peso. Pero sí podemos recordar que algunas de las decisiones más importantes de un sistema no llegan acompañadas de diagramas, revisiones de arquitectura o grandes debates.