¿Qué Es Realmente la Arquitectura de Software?

Cuando un proyecto empieza a crecer y se vuelve difícil de mantener, una frase común aparece en la conversación:
“Este proyecto necesita una mejor arquitectura.”

Pero… ¿qué significa eso, exactamente?

Spoiler: No se trata de crear carpetas controllers/, models/ y services/

Mucha gente confunde arquitectura con estructura de carpetas.
Si bien organizar los archivos ayuda, la arquitectura no es cómo acomodás tus carpetas, sino cómo se organizan las decisiones del sistema y cómo fluye la información entre sus partes.

Una buena arquitectura no se ve en el árbol de archivos. Se siente cuando:

• Entendés dónde poner cada parte del código.
• Cambiar algo no rompe otras cosas.
• Podés testear sin depender de todo el sistema.
• Tenés claro qué hace cada módulo y qué no debería hacer.

¿Entonces, Qué Hace a Una Buena Arquitectura?

Una buena arquitectura:

• Separa claramente responsabilidades.
• Minimiza el acoplamiento (cada parte depende lo menos posible de las otras).
• Permite testear fácilmente componentes aislados.
• Soporta cambios sin grandes reescrituras.
• Hace explícitas las reglas del negocio, diferenciándolas de detalles técnicos (como HTTP, bases de datos, frameworks, etc.).

Soluciones Comunes (y Por Qué No Alcanzan)

Veamos algunos enfoques populares o “de sentido común” que parecen ayudar al principio, pero muestran sus límites con el tiempo:

🧱 MVC (Model-View-Controller)

Un patrón clásico. Muchos frameworks lo implementan por defecto.

El problema:
MVC es útil para separar la interfaz de usuario del acceso a datos, pero no define claramente dónde va la lógica del negocio. Termina diluida entre modelos, controladores y helpers.
En proyectos grandes, esto se traduce en caos distribuido por capas mal entendidas.

🧬 Separación por Tipos (carpetas controllers/, services/, utils/, etc.)

Es muy común en Node.js o Express separar por tipo de archivo.

El problema:
Cuando todo está agrupado por tipo y no por funcionalidad, el código se vuelve difícil de navegar. Para entender cómo se crea una “Tarea”, tenés que saltar entre 4 carpetas distintas.
Además, al final muchas funciones terminan con lógica mezclada.

🏗️ Dividir por Rutas

“Cada endpoint tiene su propio archivo.”

El problema:
A nivel pequeño puede funcionar, pero los endpoints no deberían dictar cómo se organiza el sistema. Si todo gira alrededor de la API, se dificulta el testeo, el desacople, y se acoplan decisiones técnicas con reglas del negocio.

🔀 Monolito vs Microservicios

En algún momento alguien dice:
“El problema es que esto debería ser un microservicio.”

El problema:
Cambiar la arquitectura física (cómo se despliega el código) no resuelve un diseño mal hecho internamente.
Un microservicio mal estructurado es igual de inmantenible que un monolito desordenado.

Lo importante no es el nombre, es el pensamiento

No se trata de seguir “el patrón correcto” al pie de la letra. Se trata de entender por qué existen esos patrones y qué problemas intentan resolver.

Lo que realmente importa es el flujo del conocimiento dentro del sistema: qué capa o módulo conoce qué cosa, y quién depende de quién.

Una arquitectura bien pensada permite responder fácilmente a preguntas como:

• ¿Dónde están las reglas del negocio?
• ¿Qué partes puedo cambiar sin romper todo?
• ¿Qué módulos puedo testear sin levantar una base de datos?
• ¿Qué cosas son detalles técnicos que podrían cambiar mañana?

Conclusión: No Hay Fórmulas Mágicas, Pero Sí Buenas Preguntas

Antes de elegir una arquitectura, lo más importante es entender el problema que querés resolver.
Las soluciones simples pueden ayudar a empezar, pero tarde o temprano necesitás algo más sólido si querés mantener el control.