Arquitectura Onion: Diseño y Aplicación en Desarrollo de Software

Clase 7 de 24 • Curso de Arquitecturas Limpias para Desarrollo de Software

Resumen

¿Qué es la arquitectura cebolla y por qué es importante?

La arquitectura cebolla, también conocida como Onion Architecture, es un patrón de diseño de software propuesto en 2008 por Jeffrey Palermo. Este modelo arquitectónico es esencial porque promueve la independencia del lenguaje de programación y de las herramientas de implementación. Se centra en la separación de preocupaciones, asegurando que el núcleo de negocio no se vea afectado por cambios en otras capas como la infraestructura o la interfaz de usuario.

¿Cómo está estructurada la arquitectura cebolla?

La arquitectura cebolla se organiza en capas concéntricas, donde cada capa tiene una función específica y depende únicamente de las capas más internas. A continuación, se detalla la estructura:

Modelo de dominio: Es el corazón de la cebolla. Aquí se definen las entidades que modelan el problema que se está abordando. Por ejemplo, si se tratara de un sistema para hoteles, las entidades podrían ser "hotel", "reserva" y "habitación". Es crucial que el modelo de dominio no dependa de ninguna otra capa.
Servicios de dominio: Rodeando al modelo de dominio, esta capa contiene la lógica y las reglas de negocio. Además, aquí se definen interfaces para acceder a los datos, conocidos como repositorios, los cuales no se implementan en esta capa.
Servicios de aplicación: Esta capa envuelve a los servicios de dominio y contiene operaciones más específicas ligadas a la aplicación. Es en esta capa donde se comienza a implementar la funcionalidad de la aplicación de manera más concreta.
Capa externa: Incluye elementos que son considerados externos al núcleo pero esenciales, como las pruebas unitarias y de integración, la infraestructura, y la interfaz gráfica. Estos elementos no deben influir en el núcleo del sistema.

¿Cuáles son las ventajas del uso de la arquitectura cebolla?

Implementar la arquitectura cebolla ofrece varios beneficios significativos:

Aislamiento del dominio: La lógica del negocio se mantiene independiente de cuestiones tecnológicas como bases de datos o interfaces de usuario.
Flexibilidad y mantenimiento: Al tener las dependencias en las capas internas, facilita el mantenimiento y la adaptación a cambios.
Facilita las pruebas: Permite realizar pruebas exhaustivas de unidades e integración sin que el dominio se vea afectado.

La arquitectura cebolla ha ganado popularidad en el ecosistema .NET, pero su uso es aplicable en cualquier lenguaje de programación, confirmando su versatilidad y eficacia en la producción de software robusto y mantenible. ¡No dudes en explorar este fascinante enfoque arquitectónico y comprobar su impacto positivo en tus proyectos!

Christopher Chirino

student•

Importante: el modelo de dominio solo depende de sí mismo, en ningún momento tiene dependencia hacia las capas.

Servicios de dominio: una capa más arriba. Aquí encontramos las interfaces de esos repositorios (base de datos) para acceder a los datos. Están definidas pero no implementadas.
Servicios de aplicación: una capa más arriba, donde se encuentran las operaciones específicas. Aquí no hay interfaces.
La capa externa: incluye las diferentes pruebas que queremos usar en nuestra aplicación, así como la interfaz gráfica y la infraestructura.

Se utiliza principalmente en el ecosistema .NET.

David Alsina

student•

En Python, la arquitectura de software cebolla se puede implementar siguiendo estos elementos clave:

Núcleo (Core): Es el centro de la aplicación y contiene las reglas de negocio y la lógica principal. En el núcleo, se definen las entidades, modelos de datos y la lógica que representa el comportamiento central de la aplicación. Esta capa no debe depender de ninguna otra capa y, por lo tanto, puede ser reutilizable e independiente.
Capa de Aplicación (Application Layer): Esta capa actúa como intermediaria entre el núcleo y las capas externas, como la interfaz de usuario o servicios externos. Contiene los casos de uso de la aplicación y coordina las interacciones entre el núcleo y las capas externas. Aquí se implementan los servicios que serán expuestos a través de API o interfaz de línea de comandos.
Capa de Infraestructura (Infrastructure Layer): Es la capa más externa y se encarga de interactuar con elementos externos, como bases de datos, servicios web, sistemas de archivos, etc. La capa de infraestructura proporciona implementaciones concretas de las interfaces definidas en las capas internas. Además, maneja detalles técnicos como el almacenamiento de datos y la comunicación con recursos externos.

En una implementación típica de Onion Architecture en Python, la estructura del proyecto se organizaría en directorios, donde cada capa tiene su propio espacio y las dependencias fluyen hacia adentro, siguiendo la lógica de la cebolla:

- app/
  - core/
    - entities/
    - use_cases/
  - application/
    - services/
  - infrastructure/
    - repositories/
    - external_services/
  - interfaces/
    - web/
    - cli/

Aquí, una breve descripción de cada directorio:

core: Contiene las entidades y los casos de uso principales de la aplicación.
application: Implementa los servicios de aplicación que orquestan la lógica de negocio.
infrastructure: Proporciona implementaciones concretas para interactuar con bases de datos, servicios externos, etc.
interfaces: Aquí se encuentran las interfaces de usuario o cualquier otra interfaz para interactuar con la aplicación. Puede haber subdirectorios específicos para las interfaces web o de línea de comandos, entre otros.

Es importante destacar que la estructura exacta puede variar según los requisitos y el tamaño del proyecto. La clave está en mantener una separación clara de responsabilidades y dependencias, permitiendo así una mayor flexibilidad y mantenibilidad del software.

Bryan Castano

student•

Genial. Muchas Gracias por Vuestro Valioso Aporte para con la Clases. Me sirvio mucho vuestra explicaciion de Directorios de Capas.

Ricardo Tribaldos Hernández

student•

Onion Architecture 🧅 Fuente: dev.to

Stiven Ramírez Arango

student•

Arquitectura Cebolla

Se compone de:

Modelo de dominio: Es la capa que se encuentra más al interior de la cebolla. Se tienen las entidades que modela el problema y éstas no están relacionadas con la persistencia. Sólo tiene dependencia de sí mismo, nunca de las capas que lo están rodeando. Se denomina “modelo de objetos”, “capa de dominio” o “entidades de dominio”.
Servicios de dominio: Contiene reglas del negocio, pero un elemento fundamental es que habrán interfaces que van a representar repositorios para acceder a los datos. Se van a definir las interfaces pero no se van a implementar. Se denomina “servicio de objetos” o “capa de repositorio”.
Servicios de aplicación: Lógica de la aplicación puede estar repartida entre los servicios de aplicación y servicios de dominio. Se denomina “capa de servicios”.

Esto se denomina el núcleo del sistema.

Capa externa: Rodea al núcleo del sistema y esa pueden estar: 2. Pruebas: Unitarias, de integración y ayudar a testear que todo esté funcionando correctamente. 3. Interfaz gráfica: Es algo que puede cambiar con el tiempo. 4. Infraestructura: Se tienen elementos como acceder a un sistema de archivos, aplicaciones de terceros e integraciones varias.

Esta capa externa rodea al dominio.

Datos adicionales:

Propuesta por Jeffrey Palermo en 2008.
Arquitectura conocida principalmente en el ecosistema .NET.

Camilo Calderon

student•

Pregunta en curso de arquitectura limpia.

Trabajo dentro del ecosistema de .Net y uso la arquitectura de cebolla. Dentro del repositorio creamos 4 librerías de clases permitiendo así que cada capa tenga su propio archivo de gestor de dependencias de nuget y ve así:

Bajo mi criterio el archivo de dependencias de la capa de dominio debe estar vacío, el de la capa de Persistencia depender de la del Dominio, el de la capa de Aplicación depender de Persistencia y Dominio; y la capa WebApi puede depender de las tres anteriores.

En cuanto a librerías me genera la confusión en mi capa de persistencia, pues allí estoy usando Entity Framework, y para mí esta librería la considero parte de la infraestructura, que en mi proyecto se asociaría más a la última capa que es WebApi.

Así luce mi archivo de la librería de clases de la capa de persistencia: Persistencia.csproj

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net6.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.EntityFrameworkCore" Version="6.0.9" />
    <PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="6.0.9">
      <PrivateAssets>all</PrivateAssets>
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
    </PackageReference>
    <PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="6.0.9" />
    <PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="6.0.9">
      <PrivateAssets>all</PrivateAssets>
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
    </PackageReference>
    <PackageReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Design" Version="6.0.10" />
    <PackageReference Include="MSTest.TestFramework" Version="2.2.10" />
    <PackageReference Include="System.Data.SqlClient" Version="4.8.4" />
  </ItemGroup>

  <ItemGroup>
    <ProjectReference Include="..\Dominio\Dominio.csproj" />
  </ItemGroup>

</Project>

En mi mapa mental de asociación con respecto a la clase, Entity Framework en este caso es parte de infraestructura porque es el conector con la base de datos y por lo tanto se ubica en la capa exterior, y Persistencia que es donde tengo los repositorios, las migraciones entre otros y está ubicado en una capa interna.

En este caso, ¿estoy dañando el principio de la arquitectura en donde se menciona que la dependencia es desde afuera hacia adentro? ¿Alguien me puede dar su opinión al respecto de mi disyuntiva?

Manuel Zapata

teacher•

Persistencia pertenecería a infraestructura, y está bien que dependa de dominio. Donde se rompería la arquitectura es en la dependencia de aplicación hacia persistencia, ya que esta última pertenece a la capa externa, y se invertiría la dependencia.

Vicente Llobregat Rodriguez

student•

Termino de ver este vídeo y estoy en shock.

Me estoy dando cuenta que luego de haber combinado varias patrones de arquitectura, creyendo que aplicaba una arquitectura principalmente hexagonal, puede que haya terminado implementado la arquitectura de Cebolla sin saber que esta existía.

Nicolas Acevedo Cruz

company_admin•

Hola, no entendí nada :/

Milly Mileth Benítez Martínez

student•

Leyendo este articulo pude entender más, espero que te ayude.

https://medium.com/expedia-group-tech/onion-architecture-deed8a554423

José María C. L.

student•

Cuando se habla de servicios de dominio en esta arq., se trata de lógica con código ejecutable o son interfaces, abstractos y tipos unicamente?

Jose Bernardo Velasquez Alzate

student•

Hola, luego de ver 3 veces este video, no me queda muy claro las diferencias entre esta arquitectura y la hexagonal (port and adapters), por favor es posible tener un detalle más amplio de sus diferencias y posibles casos de uso para ambas, gracias!

Axel Yaguana

Team Platzi•

Hola. :D

La Arquitectura Limpia (Clean Architecture) y la Arquitectura Hexagonal (Hexagonal Architecture), también conocida como Puertos y Adaptadores (Ports and Adapters), son dos enfoques arquitectónicos que comparten algunos principios y objetivos, pero difieren en su estructura y énfasis. A continuación, te proporcionaré una descripción más detallada de cada una de ellas y sus posibles casos de uso.

Arquitectura Limpia (Clean Architecture):

Principios y objetivos: La Arquitectura Limpia es un enfoque basado en los principios del Desarrollo Guiado por Dominio (Domain-Driven Design) y la Separación de Responsabilidades (Separation of Concerns). Su objetivo principal es lograr un sistema modular, independiente de frameworks y tecnologías específicas, y centrado en el dominio del negocio.
Estructura: La Arquitectura Limpia se basa en el principio de Inversión de Dependencias (Dependency Inversion Principle) y se organiza en capas concéntricas. Las capas principales son: Dominio (Domain), Casos de uso (Use Cases), Interfaces de Usuario (UI) y Recursos Externos (External Resources). La capa de Dominio contiene la lógica de negocio y es la capa central y más importante del sistema.
Flujo de datos: En la Arquitectura Limpia, el flujo de datos sigue un patrón de arquitectura en forma de cebolla (onion architecture). Los datos fluyen hacia adentro desde las capas externas hacia las capas internas del sistema, y la lógica de negocio se mantiene completamente independiente de los detalles de implementación externos.
Casos de uso: La Arquitectura Limpia se centra en los casos de uso del sistema y cómo se representan en la capa de Casos de uso. Los casos de uso encapsulan la lógica de negocio y se comunican con la capa de Dominio para realizar las operaciones necesarias.

Posibles casos de uso de la Arquitectura Limpia:

Sistemas empresariales complejos con reglas de negocio sofisticadas.
Aplicaciones que necesitan ser independientes de frameworks y tecnologías específicas.
Proyectos que requieren una separación clara de responsabilidades y modularidad.
Situaciones donde se necesite tener flexibilidad para cambiar o evolucionar el sistema con el tiempo.

Arquitectura Hexagonal (Puertos y Adaptadores):

Principios y objetivos: La Arquitectura Hexagonal se basa en los principios del DDD y también busca la independencia de frameworks y tecnologías específicas. Su objetivo principal es permitir la prueba y adaptación fácil de los componentes del sistema al aislarlos de los detalles de implementación y las dependencias externas.
Estructura: La Arquitectura Hexagonal se organiza en tres capas principales: Dominio (Domain), Adaptadores (Adapters) y Controladores (Controllers). El Dominio contiene la lógica de negocio, los Adaptadores son responsables de interactuar con los componentes externos y los Controladores proporcionan las interfaces de usuario o interfaces externas para interactuar con el sistema.
Flujo de datos: En la Arquitectura Hexagonal, el flujo de datos sigue el patrón de "puertos y adaptadores". Los puertos son las interfaces que def

Manuel Zapata

teacher•

En esta imagen, puse la arquitectura cebolla al lado de la hexagonal, para facilitar la comparación.

Podemos notar algunas diferencias observando los diagramas:

La arquitectura cebolla tiene más detalle en cuanto a las capas del dominio y la capa externa.
Hexagonal es explícita en cuanto a cómo interactúa la capa externa con el dominio (a través de los puertos y adaptadores). Cebolla no es explícita en cuanto a esto.

De resto, ambas son arquitecturas limpias, y tienen los mismos casos de uso, independiente del nivel de detalle que ambas manejan.

ANDRES ALFONSO MIRA MEJIA

student•

✅

Arquitectura Onion: Diseño y Aplicación en Desarrollo de Software

Introducción al curso

Arquitectura Limpia: Enfoque y Aplicación en Java y C#

Conceptos detrás de las Arquitecturas Limpias

Arquitectura de Software: Tres Capas y MVC

Características y Beneficios de la Arquitectura Limpia

Cuándo aplicar o ignorar arquitecturas limpias en desarrollo software

Principios SOLID: Aplicación Práctica en Arquitecturas Limpias

Arquitecturas de referencia

Arquitectura Hexagonal: Puertos y Adaptadores en Desarrollo de Software