La búsqueda de la arquitectura correcta
Durante años he participado en debates y proyectos donde se buscaba la arquitectura correcta. La que, en teoría, funciona siempre. La que se repite en charlas, artículos y repositorios de referencia.
El patrón suele ser parecido: se identifica una arquitectura que ha funcionado en otro sitio, se adapta ligeramente y se aplica al proyecto actual. A veces funciona. Otras veces no tanto.
Cuando falla, rara vez es porque la arquitectura sea “mala”. Falla porque no encaja con el contexto en el que se aplica.
No suele ser una cuestión de falta de criterio, sino la inercia de mantener una idea muy extendida: que existe una forma correcta de hacer las cosas, independientemente de las circunstancias.
Con el tiempo, mi percepción ha ido cambiando. Cada vez me resulta más claro que la arquitectura no puede evaluarse sin entender el contexto en el que vive.
La idea de las “buenas prácticas”
En el ecosistema .NET es habitual encontrar una fuerte presencia de ciertos enfoques: Clean Architecture, patrones tácticos de DDD, separación estricta por capas, CQRS o el uso sistemático de mediadores.
Todos ellos tienen sentido en determinados escenarios. El problema aparece cuando se aplican de forma automática, sin preguntarse si realmente aportan valor al problema que se está resolviendo.
En proyectos sencillos, con reglas de negocio claras y equipos pequeños, este tipo de estructuras puede introducir una complejidad que no siempre se justifica. Más archivos, más abstracciones y más conceptos que mantener en la cabeza del equipo.
Desde mi experiencia, una arquitectura funciona bien cuando resuelve el problema de negocio con un coste razonable, tanto económico como cognitivo. No cuando cumple un checklist de patrones.
Qué entiendo por contexto
Cuando hablo de contexto no me refiero solo al código ni a las tecnologías elegidas. Me refiero al conjunto de factores que hacen que una decisión técnica tenga sentido en un momento concreto.
Hay muchos, pero hay tres que considero especialmente relevantes.
Negocio
No es lo mismo construir un MVP que necesita validarse rápidamente que un sistema core que va a sostener una parte crítica del negocio durante años.
En el primer caso, el tiempo y la capacidad de iterar suelen pesar más que la perfección estructural. En el segundo, la mantenibilidad y la estabilidad se vuelven prioritarias.
Diseñar ambos escenarios de la misma forma suele ser una señal de que algo importante se está dejando fuera de la ecuación.
Equipo
Este es uno de los factores más determinantes y, sin embargo, menos visibles en muchos debates arquitectónicos.
La experiencia real del equipo importa. Mucho.
Si un equipo no está familiarizado con Kubernetes, introducir AKS como plataforma base añade un riesgo que va más allá de la tecnología en sí. Afecta a la capacidad de operar el sistema, de diagnosticar problemas y de mantenerlo en el tiempo.
Desde mi punto de vista, la arquitectura debería adaptarse al equipo que mantiene el sistema, no al equipo ideal que nos gustaría tener.
Coste
La nube ofrece muchas posibilidades, pero no elimina las decisiones arquitectónicas. Simplemente cambia dónde se manifiestan sus costes.
En escenarios con carga constante y predecible, una solución basada en App Service o en infraestructuras más tradicionales puede ser más sencilla y, en algunos casos, más económica que una arquitectura altamente distribuida o serverless.
No se trata de elegir “lo moderno” frente a “lo clásico”, sino de entender qué se está pagando a cambio.
Un ejemplo habitual: monolito y evolución
Un escenario bastante común es el de una startup con un equipo reducido, un dominio aún en evolución y la necesidad de moverse rápido.
En ese contexto, un monolito bien estructurado, desplegado de forma sencilla y con una base de datos centralizada, puede ser una solución muy eficaz. Facilita la refactorización, reduce la latencia interna y mantiene bajos los costes operativos.
Eso no significa ignorar el futuro ni asumir que todo será fácil de cambiar. Significa aceptar que las primeras decisiones condicionan cómo podrá evolucionar el sistema más adelante.
Con el paso del tiempo, ese mismo sistema puede crecer. El equipo aumenta, los dominios se clarifican y aparecen necesidades de escalado independiente. La forma en la que se haya construido el monolito inicial marca hasta qué punto esa evolución será gradual o traumática.
En ese momento, empezar a extraer responsabilidades en servicios independientes y adoptar comunicación asíncrona puede tener sentido. No como un reinicio, sino como una continuación del camino iniciado.
La clave no está en elegir entre monolito o microservicios, sino en entender que la arquitectura correcta hoy puede no serlo mañana, y que cada decisión deja huella en cómo se podrá cambiar después.
No todo es fácilmente reversible, y no todo se puede deshacer sin coste. Precisamente por eso, pensar en la evolución no significa posponer nada, sino asumir con más cuidado lo que se decide desde el principio.
Trade-offs como forma de trabajo
Toda decisión arquitectónica implica una renuncia.
Adoptar microservicios permite escalar de forma independiente y desacoplar equipos, pero introduce complejidad en observabilidad, despliegue y gestión de fallos distribuidos.
Aplicar una arquitectura muy estructurada mejora la testabilidad y la separación de responsabilidades, pero también incrementa el número de piezas que el equipo debe comprender y mantener.
Con el tiempo, he llegado a una conclusión bastante simple:
El trabajo del arquitecto no es diseñar sistemas perfectos,
sino elegir conscientemente qué problemas está dispuesto a asumir.
Cuando la arquitectura se vuelve real
En la práctica, la arquitectura deja de ser interesante cuando se discute en abstracto y empieza a importar cuando hay que convivir con ella.
Cuando el sistema crece, cuando el equipo cambia, cuando aparecen límites que no estaban en el diagrama inicial. Es ahí donde se ve si una decisión estaba bien situada o no.
No se trata de haber acertado siempre, sino de haber entendido qué se estaba aceptando en ese momento. Al final, una buena arquitectura no es la que no tiene deuda técnica, sino aquella donde la deuda fue elegida conscientemente y no asumida por accidente.