Esta es la contestación más correcta que encomtrarás compartir, pero primero obsérvala pausadamente y valora si es compatible a tu trabajo.
¿Cuáles son las diferencias entre ellos, si las hay?
Cebolla: Hay capas, con las dependencias siempre apuntando hacia adentro, es decir, una capa puede usar cualquiera de las capas dentro de ella. La capa interna es el modelo de dominio y la externa es la infraestructura, pero la cantidad de capas entre ellas puede variar.
Hexagonal (es un nombre alternativo para el nombre original “Puertos y adaptadores”): No hay capas. Tienes la aplicación, los puertos y los adaptadores. Los puertos pertenecen a la aplicación, son la API/SPI de la aplicación. Los adaptadores están fuera de la aplicación y cada uno depende de un puerto de la aplicación.
La confusión que tienen algunas personas es que al implementar la arquitectura hexagonal, la mayoría de las personas no colocan físicamente todos los adaptadores en un artefacto, sino que los juntan en un solo artefacto (como la capa de infraestructura). Y también dependen de los adaptadores en toda la aplicación, no solo del puerto que usan. Así que sería una cebolla de hecho.
La implementación de la derecha hexagonal debe separar los adaptadores entre sí, y cada adaptador debe depender solo del puerto que usa/implementa (dependiendo de si el puerto es un controlador o un controlador).
Otra diferencia es que Hexagonal no dice nada sobre la estructura del interior del hexágono (la aplicación).
¿Cuáles son los beneficios de usar uno sobre el otro?
El beneficio de hexagonal es que es más modular, tiene una clara separación de componentes, evitando la fuga de código entre ellos. Onion, por otro lado, es más peligroso en ese sentido, ya que puede acceder, por ejemplo, a la base de datos directamente desde la interfaz de usuario (ambos pertenecen a la misma capa).
El beneficio de Onion se deriva de lo anterior. Dado que hexagonal tiene muchos artefactos, si el proyecto es grande, la construcción de todo el proyecto debería llevar mucho tiempo.
¿Por qué lo usarías? ¿Cuándo usarlo?
El punto de usar cualquiera de ellos es que te enfocas en el problema real que estás tratando de resolver, sin usar ninguna tecnología o marco. La aplicación es independiente de la tecnología y es fácil migrar de un marco a otro. Ambos se llaman arquitecturas “limpias” por eso. Tiene el núcleo de su aplicación libre de código de marco, anotaciones, etc.
Entonces… ¿Por qué usarlos?
Porque mejora la mantenibilidad, la capacidad de prueba y tiene un código limpio.
¿Cuándo usarlos?
Preferiría decir cuándo no usarlos. Si la aplicación que estás desarrollando no es compleja, por ejemplo, es solo un CRUD, tal vez no merezca usarlos.
Personalmente, me gusta “Puertos y adaptadores” sobre los demás.
Espero que mi explicación haya ayudado.
Las respuestas anteriores hacen una declaración fundamentalmente incorrecta sobre la arquitectura Onion. Afirman que “en Onion, la interfaz de usuario y el acceso a los datos son parte de la misma capa”. La confusión podría provenir de pensar que todas las capas hablan con todo lo que está por encima y por debajo de ellas.
En realidad, un diagrama Onion es una mala representación de la Arquitectura Onion. El key La conclusión es que la capa de dominio central es independiente de las capas circundantes y las capas circundantes generalmente también son independientes entre sí. Por lo general, esto significa que una interfaz de usuario se comunica con un servicio que se comunica con las capas de datos y dominio. La interfaz de usuario no interactúa directamente con las otras capas, y las interacciones de las capas se abstraen mediante la inserción de dependencias y la segregación de interfaces.
Que yo sepa, no hay patrones arquitectónicos que aconsejen mezclar el acceso a datos y la interfaz de usuario (algunos, como Active Record, combinan Business y Data Access). Por separado, hay tecnologías que producen código que evita las capas; las herramientas de desarrollo rápido a menudo hacen esto, pero esas son herramientas que favorecen la velocidad de implementación sobre el diseño y la capacidad de mantenimiento.
Cebolla, Hexagonal y Puertos y Adaptadores son, de hecho, nombres diferentes para la misma arquitectura conceptual.
Mark Seeman tiene una excelente publicación que ayuda a aclarar cómo las diferencias, si las hay, son marginales y semánticas: capas, cebollas, puertos, adaptadores: todo es lo mismo
Acuérdate de que puedes esclarecer .