Cuando estructuras una aplicación, dos enfoques aparecen casi siempre sobre la mesa: la arquitectura de tres capas y el patrón modelo vista controlador (MVC). Ambos sirven para organizar el código, pero arrastran limitaciones que terminan empujándote hacia propuestas como las arquitecturas limpias.

Entender estos modelos te da el punto de partida para diseñar software mantenible, con responsabilidades claras y lógica de negocio que no se filtre por todas partes.

¿Qué es la arquitectura de tres capas y cómo se organiza?

La arquitectura de tres capas divide tu aplicación en bloques con responsabilidades específicas. Cada capa habla con la siguiente y nada más.

• Capa de presentación: interactúa con el usuario. Puede ser web, móvil o desktop, da igual el medio.
• Dominio: aquí vive la lógica de negocio, las validaciones y los cálculos.
• Capa de datos: se comunica con la base de datos, normalmente relacional como Postgres o SQL Server, aunque también podría ser NoSQL.

Pueden existir más o menos capas, pero tres es lo más común en la práctica [0:30].

¿Qué hace la capa de dominio? Contiene la lógica de negocio: validaciones, cálculos y reglas que definen cómo se comporta tu aplicación, sin importar la interfaz ni la base de datos.

¿Cómo funciona el patrón MVC y qué rol juega el controlador?

El modelo vista controlador es la otra forma clásica de estructurar una aplicación. La idea es repartir responsabilidades entre tres piezas que conversan entre sí [1:20].

• Vista: maneja la interacción con el usuario y genera peticiones.
• Controlador: recibe esas peticiones y decide qué hacer con ellas. Yo lo comparo con un 10 en un equipo de fútbol, ese jugador que sabe cómo repartir el juego.
• Modelo: ejecuta la lógica de negocio y accede a los datos.

Dependiendo de la implementación, puede existir interacción directa entre el modelo y la vista, pero esa es la estructura base que vas a encontrar.

¿Cuál es la diferencia entre MVC y arquitectura de tres capas? En tres capas el flujo es lineal de presentación a datos pasando por dominio. En MVC el controlador actúa como orquestador entre la vista y el modelo, y el modelo concentra lógica y persistencia.

¿Qué limitaciones tienen MVC y la arquitectura de tres capas?

Aquí viene lo interesante, porque ambos enfoques cargan con problemas que se sienten apenas el proyecto crece [2:30].

Desarrollo centrado en la base de datos

Todo termina convergiendo en la base de datos, casi siempre relacional. Tanto, que lo primero que diseñas es el esquema de datos y desde ahí construyes hacia arriba. La lógica de negocio queda subordinada a la persistencia, como si no existiera sin un lugar donde almacenar.

Integraciones que no encuentran su lugar

Si necesitas tocar la interfaz, sabes que vas a la presentación. Si es lógica, al dominio. Si agregas una columna, a la capa de datos. Pero, ¿y si integras una red social o un sistema de archivos? Ahí la arquitectura se vuelve borrosa porque no es explícita sobre dónde colocar esas piezas.

Lógica de negocio que se filtra

Esta es la trampa más común. Empiezas a ver reglas de negocio dentro de un click de botón en la interfaz, cuando deberían vivir en otra capa. Pasa por tomar atajos o porque la arquitectura no es clara, y el costo es alto: pierdes la posibilidad de reutilizar esa lógica en otros contextos.

¿Por qué la lógica de negocio no debe estar en la vista? Porque si la metes en un botón o en un componente visual, no puedes reutilizarla desde otra interfaz, otro endpoint o un proceso automático. Queda atrapada.

¿Por qué surgen las arquitecturas limpias como alternativa?

Las arquitecturas limpias aparecen justamente para resolver estos cuatro puntos: dependencia excesiva de la base de datos, lógica acoplada a la persistencia, integraciones sin lugar definido y reglas de negocio que se filtran [4:30].

La propuesta es organizar mejor la lógica de negocio y dejar explícitas las dependencias entre componentes, algo que ni tres capas ni MVC resuelven con claridad.

Cuéntame en los comentarios si ya habías trabajado con arquitectura de tres capas o con MVC, y qué tipo de proyectos llevaste con esos enfoques.