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.
#La idea común
Hexagonal (2005), Onion (2008) y Clean (2012) son variantes de la misma idea: el dominio en el centro y las dependencias apuntando hacia adentro (Dependency Inversion). Lo que cambia es el vocabulario y cuánto prescriben de la estructura interna. Layered, en cambio, suele hacer lo contrario: el dominio depende de la capa de datos.
#Tabla comparativa
| Eje | Layered | Hexagonal | Onion | Clean | Vertical Slice |
|---|---|---|---|---|---|
| Autor / año | Clásica | Cockburn, 2005 | Palermo, 2008 | R. Martin, 2012 | Bogard, ~2018 |
| Metáfora | Pila de capas | Hexágono con puertos | Cebolla | Círculos concéntricos | Rebanadas por feature |
| Dirección de dependencias | Hacia abajo (dominio → datos) | Hacia el núcleo | Hacia el centro | Hacia el centro | Dentro de la slice |
| Estructura interna | Capas fijas | Solo adentro/afuera | Modelo, dominio, aplicación | 4 capas nombradas | Libre por feature |
| Protagonista | La capa | Los puertos | El modelo de dominio | Los casos de uso | La feature |
| Prescriptiva | Poco | Poco | Media | Mucho | Poco |
| Ceremonia | Baja | Media | Media | Alta | Baja |
| Testeabilidad del dominio | Media | Alta | Alta | Alta | Media-alta |
| Mejor para | CRUD, apps simples | Integraciones y varios clientes | Dominios ricos (DDD) | Equipos grandes con convenciones | APIs con muchas features independientes |
#Hexagonal vs Onion vs Clean
- Hexagonal enfatiza la simetría entre lo que entra (driving) y lo que sale (driven). Es la más liviana y no te dice cómo ordenar el núcleo.
- Onion enfatiza el modelo de dominio y agrega capas internas (servicios de dominio y de aplicación).
- Clean enfatiza los casos de uso y define las capas y el cruce de datos entre ellas.
- Se pueden combinar: es común un núcleo Onion/Clean cuyo borde se organiza como puertos y adaptadores.
#Layered vs las otras
La diferencia práctica es quién depende de quién. En Layered clásica, el negocio referencia el acceso a datos; en las otras, el negocio define la interfaz y la infraestructura la implementa. Si tu aplicación es CRUD y el negocio es trivial, Layered con buenas prácticas alcanza.
#Vertical Slice: otro eje
Vertical Slice no compite con Hexagonal: organiza por feature en vez de por capa. Se puede aplicar dentro de cada slice un enfoque pragmático (handler directo a EF para queries simples) y reservar un dominio rico para las slices donde hay reglas.
#Preguntas clave para elegir
| Pregunta | Si la respuesta es… | Tendé a |
|---|---|---|
| ¿Hay reglas de negocio complejas? | No, es CRUD | Layered o Vertical Slice |
| ¿La aplicación vivirá años con muchos cambios? | Sí | Hexagonal / Onion / Clean |
| ¿Hay varios puntos de entrada (API, jobs, CLI) o varios proveedores externos? | Sí | Hexagonal |
| ¿Usan DDD con dominio rico? | Sí | Onion o Clean |
| ¿El equipo es grande y necesita convenciones explícitas? | Sí | Clean |
| ¿Cuesta agregar una feature porque hay que tocar 5 carpetas? | Sí | Vertical Slice |
| ¿El equipo tiene poca experiencia con DI y abstracciones? | Sí | Empezá con Layered bien hecha |
Regla: no elijas por el nombre. Elegí por el problema. Si el dominio es simple, la arquitectura más simple que mantenga la regla de dependencia sana es la correcta. Se puede evolucionar de Layered a Hexagonal cuando el dolor aparezca; el camino inverso es más raro.
| Estilo | Pro principal | Contra principal |
|---|---|---|
| Layered | Simplicidad | El dominio depende de la infraestructura |
| Hexagonal | Liviana, aísla bordes | No guía el interior |
| Onion | Foco en el dominio | Vocabulario similar a las otras |
| Clean | Muy explícita | Ceremonia y boilerplate |
| Vertical Slice | Cohesión por feature | Duplicación entre slices |
#comparison #architecture