Arquitectura de aplicación

Cómo se organiza una aplicación de extremo a extremo. Layered, Hexagonal, Clean, MVC, MVVM, BFF, Vertical Slice.

Los patrones de arquitectura de aplicación definen la forma en que estructurás una aplicación completa: dónde vive la lógica de negocio, cómo entran y salen los datos, qué dependencias están permitidas entre capas y cómo se aíslan los detalles de infraestructura.

#El problema

Sin una arquitectura clara, todo termina en el mismo lugar: la UI conoce la base de datos, el dominio importa el ORM, y un cambio de framework implica reescribir el negocio. La aplicación crece como una única pila inestable: tirás de un ladrillo y se cae todo. Los tests requieren levantar Postgres, HTTP y una luna llena. Los bugs aparecen en lugares que no tienen relación con lo que cambiaste.

#La solución

Una arquitectura de aplicación define fronteras explícitas entre las partes y reglas claras de quién puede llamar a quién. El dominio queda aislado de los detalles, la UI se vuelve reemplazable, y los tests del negocio corren en milisegundos sin tocar infraestructura. El framework deja de ser el centro: es un detalle más, intercambiable.

#Por qué importan más que los patrones de diseño

Un patrón de diseño mal elegido se puede refactorizar en una tarde. Una arquitectura mal elegida te puede acompañar durante años. Es el contrato implícito que tu equipo firma sobre cómo se va a escribir todo lo que venga.

#Cuándo encajan

  • El proyecto va a vivir más de seis meses con varias personas tocando el código.
  • Hay reglas de negocio que importan más que la base de datos o el framework.
  • Querés poder reemplazar la UI, el ORM o el broker de mensajes sin reescribir el dominio.
  • Necesitás tests que no levanten Postgres ni HTTP.

#Cuándo NO los apliques en serio

  • Para un script de migración, un microservicio de 200 líneas o un prototipo.
  • Clean Architecture en una app CRUD trivial es más caro que el problema que resuelve.
  • Hexagonal sin tests reales del dominio es solo más carpetas.

#En este capítulo

  • Layered — la clásica de toda la vida.
  • Hexagonal / Ports & Adapters — el dominio en el centro, la infra en los bordes.
  • Clean Architecture — versión opinada de Hexagonal con dependencias dirigidas hacia adentro.
  • MVC / MVVM — arquitecturas centradas en la UI.
  • Vertical Slice — organizar por feature en lugar de por capa.
  • BFF — un backend dedicado por experiencia de usuario.

#Lecturas relacionadas

  • Layered (N-Tier) — Organiza la aplicación en capas con dependencias unidireccionales: Presentación → Aplicación → Dominio → Infraestructura.
  • Clean Architecture — Organiza el código en capas concéntricas donde el dominio es el centro y nada de fuera lo toca.
  • Hexagonal (Ports & Adapters) — El dominio define puertos (interfaces); cada actor externo (DB, UI, MQ) llega a través de un adaptador.
  • Vertical Slice Architecture — Organiza el código por feature en lugar de por capa: cada slice contiene Web + App + Domain + Infra de una funcionalidad.
  • MVC — Separa el modelo (datos), la vista (UI) y el controlador (input) en componentes independientes.
  • MVVM — View ↔ ViewModel ↔ Model: el ViewModel expone estado bindable y comandos.
  • Backend for Frontend (BFF) — Un backend dedicado por tipo de cliente (web, móvil, smart TV) que adapta el modelo a sus necesidades.