ARQUITECTURA ONION O CEBOLLA

Existen numerosas arquitecturas para implementar proyectos, ya sea mvc o api rest, pero casi todas
las arquitecturas existentes como la de capas presentan una posible desventaja

La principal desventaja de este planteamiento es que la última capa es la de acceso a

datos. Esto implica que todas las demás capas, incluyendo una posible de interfaz de
usuario, acaba dependiendo de ella bien de forma directa, es decir que están
fuertemente acopladas a esta.
En muchos casos para algunos sistemas puede llegar a encajar o no ser una
desventaja demasiado importante como para tenerla en cuenta, pero aún así es algo a
en lo que hay que reflexionar.
¿Que sucede cuando nuestra aplicación empieza a crecer o a escalar?
Normalmente se convierte en un problema y por eso han surgido otras arquitecturas
que intentan solucionarlo, aunque no dejan de ser una versión ligeramente distinta y
con un nombre llamativo de las arquitecturas multicapas ligeramente modificadas
para implementar adecuadamente el principio de inversión de dependencia (SOLID).
Según este principio debemos depender de las abstracciones en lugar de hacerlo de
las clases concretas. En breve vemos cómo hacen esto y como al final todo sigue
siendo una arquitectura multicapa bien diseñada. Pero al momento de querer hacer
nuestra aplicación  mas apta a mantenimiento y cambios de requerimiento e ahí
donde esta el inconveniente.
¿Como solucionar este Detalle?

Para las empresas que quieren solucionar el detalle anterior necesitarían

implementar una arquitectura que permita todo lo anterior, para esto lo mas
recomendable es utilizar la Arquitectura Onion o de cebolla, que fue bautizada así
por Jeffrey Palermo

A grandes rasgos se trata de una arquitectura multicapa construida en torno a

un modelo de dominio independiente de todo lo demás. Las dependencias van hacia
el centro, por lo que todo depende de ese modelo de dominio. A su alrededor se
organizan varias capas, estando en las más cercanas las interfaces de repositorio, es
decir, las que definen el comportamiento del almacenamiento de los datos pero no lo
implementan. En las capas siguientes está la lógica de negocio que usa estas
interfaces y que en tiempo de ejecución tendrá las implementaciones apropiadas.
Alrededor del núcleo de modelo puede haber un número variable de capas, pero
siempre debe cumplirse que las interfaces estén más cerca que las clases que las
utilizan. Con esto ya tenemos creado el core lógico de nuestra aplicación, que no
tiene absolutamente ningún detalle de infraestructura.

Por último, en la capa más exterior es donde estarán todos los detalles de

comunicación con el exterior (tanto de interfaz con el usuario como el
almacenamiento) y los tests de integración. Las clases que se presentan aquí
implementarán las interfaces que se definen en las capas inferiores, pudiendo
cambiar por tanto las implementaciones dependientes de la tecnología sin que las
capas inferiores se enteren. Lo que conseguimos de esta manera es una arquitectura
que habla de cómo está montado el sistema y no de los terceros que se comunican
con él.