Comprender cómo se organizan las capas de un sistema es fundamental para construir software mantenible y desacoplado. La arquitectura cebolla (onion architecture) ofrece un modelo donde el dominio ocupa el centro y todo lo demás lo rodea, garantizando que las dependencias siempre apunten hacia adentro. A continuación se explican sus capas, su propósito y los detalles que la hacen relevante en el desarrollo moderno.
¿Qué es el modelo de dominio y por qué es el centro de la cebolla?
El modelo de dominio es la capa más interna de la arquitectura [0:18]. Aquí se definen las entidades que representan el problema que se está resolviendo. Si se modela un sistema para hoteles, por ejemplo, aparecerán entidades como hotel, reserva y habitación.
Una regla esencial: el modelo de dominio solo puede depender de sí mismo [0:55]. No debe tener dependencias hacia las capas exteriores. Este principio protege la lógica central de cambios tecnológicos o de infraestructura. También se le conoce como modelo de objetos, capa de dominio o entidades de dominio; todos son nombres alternos para el mismo concepto [1:07].
¿Qué papel cumplen los servicios de dominio?
Rodeando al modelo de dominio se encuentran los servicios de dominio [1:17]. En esta capa aparecen reglas y lógica de negocio, pero su elemento más característico son las interfaces de repositorio.
- Un repositorio es un objeto especializado que se conecta a bases de datos —relacionales, no relacionales o cualquier almacén de información— [1:35].
- Las interfaces se definen aquí, pero no se implementan en esta capa [1:52].
- Otros nombres comunes: servicio de objetos o capa de repositorio [1:58].
Esta separación entre definición e implementación es clave porque permite cambiar la tecnología de persistencia sin afectar la lógica central.
¿Cómo se diferencian los servicios de aplicación?
La siguiente capa corresponde a los servicios de aplicación [2:10]. Aquí la lógica de negocio se vuelve más específica y operacional. La diferencia con los servicios de dominio es que estos últimos contienen reglas generales del negocio, mientras que los servicios de aplicación orquestan operaciones concretas [2:28].
- La lógica de negocio puede repartirse entre ambas capas.
- Las interfaces se definen en la capa interna, no aquí.
- También se conoce como capa de servicios [2:40].
Estas tres capas —modelo de dominio, servicios de dominio y servicios de aplicación— conforman el núcleo del sistema [2:47].
¿Qué elementos componen la capa externa de la arquitectura?
Todo lo que rodea al núcleo pertenece a la capa externa y se divide en tres grandes bloques [3:00].
- Pruebas: tanto unitarias como de integración. Se consideran externas al núcleo porque validan el comportamiento sin formar parte del dominio [3:06].
- Interfaz gráfica: es ajena al dominio del problema y puede cambiar con el tiempo. Lo importante es que el dominio nunca dependa de la interfaz gráfica [3:24].
- Infraestructura: incluye acceso al sistema de archivos, integraciones con aplicaciones de terceros y cualquier componente que no encaje como interfaz gráfica ni como prueba [3:40].
Esta separación garantiza que un cambio en la tecnología de frontend o en un servicio externo no obligue a modificar las reglas centrales del negocio.
¿Cuál es el origen de la arquitectura cebolla?
Fue propuesta por Jeffrey Palermo en 2008 [4:07], aunque ya la venía trabajando desde antes de esa fecha. La formalizó en una serie de artículos que documentan su enfoque.
Un dato relevante es que esta arquitectura es especialmente popular en el ecosistema .NET y C#, debido al background de Palermo [4:22]. Sin embargo, al tratarse de una arquitectura limpia, es completamente independiente del lenguaje de programación [4:38]. Puede aplicarse en cualquier tecnología porque sus principios se centran en la organización de responsabilidades, no en herramientas específicas.
Si ya trabajas con alguna variante de arquitectura limpia o estás evaluando cómo estructurar tu próximo proyecto, comparte en los comentarios cómo organizas tus capas y qué dudas te surgen sobre este modelo.
