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.
  • Onion — capas concéntricas con el modelo de dominio al centro.
  • Clean Architecture — versión opinada con casos de uso como protagonistas y dependencias hacia adentro.
  • Comparativa — en qué se parecen y se diferencian Layered, Hexagonal, Onion, Clean y Vertical Slice.
  • 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.

#Cómo elegir: preguntas clave

No hay una arquitectura "mejor". Respondé esto antes de elegir:

  1. ¿Qué tipo de aplicación es? Cliente con UI (mobile/desktop) → MVVM. Web server-side → MVC. API o backend → Layered, Hexagonal, Clean o Vertical Slice.
  2. ¿Cuánto vive y cuánto cambia el negocio? Prototipo o CRUD simple → Layered. Reglas complejas y larga vida → Hexagonal / Clean.
  3. ¿Qué tamaño tiene el equipo? Pocas personas → lo más simple que funcione. Muchos equipos → fronteras explícitas (Vertical Slice, módulos).
  4. ¿Qué presupuesto y madurez operativa hay? Poco → monolito modular, no microservicios.
  5. ¿Hay un cuello de botella medido? Sin datos, no optimices la arquitectura por intuición.
  6. ¿Cuántos clientes distintos consumen el backend? Varios (web, mobile, terceros) → considerá BFF.
  7. ¿Hexagonal, Onion o Clean? Comparten la misma idea (dominio al centro) y se diferencian en vocabulario y grado de prescripción: ver la comparativa.

La arquitectura de aplicación (cómo organizás el código) es independiente del estilo de despliegue (cómo lo ejecutás). Podés tener Hexagonal dentro de un Modulith o de un microservicio. Para decidir entre Monolito, Modulith y Microservicios, mirá la comparativa.

#Lecturas relacionadas

  • Layered (N-Tier) — Organiza la aplicación en capas con dependencias unidireccionales: Presentación → Aplicación → Dominio → Infraestructura.
  • Hexagonal (Ports & Adapters) — El dominio define puertos (interfaces); cada actor externo (API, DB, cola, tests) llega a través de un adaptador intercambiable.
  • Onion Architecture — Capas concéntricas con el modelo de dominio en el centro; las dependencias apuntan hacia adentro y la infraestructura queda en el borde.
  • Clean Architecture — Organiza el código en capas concéntricas donde el dominio es el centro y nada de fuera lo toca.
  • 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.
  • Comparativa: Layered, Hexagonal, Onion, Clean y Vertical Slice — En qué se parecen y en qué se diferencian las arquitecturas de aplicación más usadas, y cómo elegir entre ellas.