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.

Contexto

Propuesta por Jeffrey Palermo en 2008, antes que Clean Architecture. Parte de una crítica a la arquitectura en capas clásica: el dominio terminaba dependiendo de la capa de datos, y por eso la base de datos era el verdadero centro del sistema.

Problema

En una arquitectura en capas tradicional (UI → Negocio → Datos), el negocio referencia la capa de acceso a datos. Cambiar el ORM o testear el negocio sin base de datos se vuelve costoso.

Solución

Capas concéntricas, con una sola regla: el código solo puede depender de capas más internas.

┌───────────────────────────────────────────────┐
│  UI · Infraestructura · Tests                 │  ← Externa (detalles)
│  ┌─────────────────────────────────────────┐  │
│  │  Servicios de aplicación                │  │
│  │  ┌───────────────────────────────────┐  │  │
│  │  │  Servicios de dominio             │  │  │
│  │  │  ┌─────────────────────────────┐  │  │  │
│  │  │  │  Modelo de dominio          │  │  │  │  ← Centro
│  │  │  │  (entidades, value objects) │  │  │  │
│  │  │  └─────────────────────────────┘  │  │  │
│  │  └───────────────────────────────────┘  │  │
│  └─────────────────────────────────────────┘  │
└───────────────────────────────────────────────┘
  1. Modelo de dominio (centro): entidades y value objects, sin dependencias.
  2. Servicios de dominio: reglas que no pertenecen a una sola entidad. Aquí viven también las interfaces de repositorio.
  3. Servicios de aplicación: orquestan casos de uso.
  4. Exterior: UI, persistencia, servicios externos y tests. Implementan las interfaces definidas hacia adentro.

#Estructura típica en .NET

CSHARP 
src/
├── Core/
│   ├── Domain/          ← Entidades, value objects, interfaces de repositorio
│   └── Application/     ← Servicios de aplicación, DTOs
├── Infrastructure/      ← EF Core, clientes HTTP, mensajería
└── Web/                 ← API/UI, composición de DI

#Qué la distingue

  • Es la que más enfatiza el modelo de dominio como centro y la separación entre servicios de dominio y de aplicación.
  • Menos prescriptiva que Clean: no define una capa de "interface adapters" ni reglas sobre cómo viajan los datos entre capas.
  • Más estructurada que Hexagonal: define capas internas, no solo adentro/afuera.
  • En la práctica, muchas plantillas .NET llamadas "Clean Architecture" son, estrictamente, Onion: Domain, Application, Infrastructure, Web.

Ver la comparativa completa.

Cuándo NO aplicarlo
  • Aplicaciones CRUD sin dominio rico.
  • Si el equipo no distingue servicio de dominio de servicio de aplicación: las capas se vuelven carpetas vacías de significado.
Tradeoffs
Pro Contra
Dominio independiente de la persistencia Más proyectos y mapeos
Fuerte alineación con DDD La frontera domain service / application service confunde
Testeable sin infraestructura Es la misma idea que Hexagonal/Clean con otro vocabulario: fácil sobre-debatir los nombres

#architecture #onion #ddd