Artículos relacionados:
- c# Principios SOLID – Caso práctico: Módulo de seguridad Parte 1
- c# Object oriented design – Dependency Inversion ¿Cómo aplicas este principio?
Introducción
El termino Onion Architecture o Arquitectura cebolla fue acuñada por Jeffrey Palermo, siendo su primer artículo publicado en el año 2008 donde habla de este tema. En este artículo al autor señala que este tipo de arquitectura es ideal para aplicaciones con un comportamiento complejo del negocio o que van a tener un tiempo de vida largo. Se debe tener en cuenta que este tipo de arquitectura no es ideal para aplicaciones pequeñas, si se aplica a una aplicación que solo realiza operaciones CRUD o no tiene nada de complejidad obtendremos como resultado que nuestro diseño sufra del design smell de Complejidad innecesaria. La Onion Architecture nació por el gran problema que existe con el muy usado estilo NCapas en donde las capas superiores dependen de las inferiores y de algunos temas de infraestructura (base de datos, servicios web, servidores de correo, servidores ftp, etc), pero el principal punto en contra que tiene el estilo NCapas es el acoplamiento innecesario que genera entre las capas (inferiores y superiores) y entre varias responsabilidades de infraestructura. Además, se debe mencionar que la Onion Architecture está muy relacionado con el principio SOLID Dependency Inversion por lo que es necesario contar con algún mecanismo de inyección de dependencias. A continuación veamos las características del estilo tradicional NCapas contra Onion Architecture.
Arquitectura en N capas:
Problemas
- Cada capa esta acoplada a la capa inferior, este diseño crea un acoplamiento innecesario.
- Cada capa depende sobre algunos temas de infraestructura.
- La capa de presentación depende indirectamente de la capa de datos, cualquier cambio que ocurra en base de datos tendrá un impacto sobre las capas superiores.
- La capa de presentación no puede funcionar si la capa de negocio no está presente y la capa de negocio no funciona si no existe la capa de datos.
- Este diseño viola el principio SOLID Dependency Inversion que indica lo siguiente: Abstractions should not depend upon details. Details should depend upon abstractions.
- La capa de negocio (abstracción) no debe depender de la de datos (detalle). Los detalles deben depender de las abstracciones.
Onion Architecture:
La regla principal es que todo el código debe depender de las capas centrales y no de las externas.
Finalidad:
La finalidad de este estilo de arquitectura es poder construir aplicaciones que sean fáciles de mantener, probar y sobre todo que se encuentren desacopladas de elementos de infraestructura tales como base de datos o servicios.
- Independencia de frameworks: La arquitectura no debe depender de ninguna librería. Esto permite usar frameworks como herramientas.
- Testeable: Las reglas de negocio pueden ser testeadas sin necesidad de conocer la interfaz de usuario, la base de datos o algún servicio externo.
- Independiente de la UI: La interfaz de usuario puede cambiar fácilmente sin tener que afectar al resto del sistema. Un tipo de interfaz de usuario puede ser reemplazada por otra sin cambiar las reglas de negocio.
- Independiente de la base de datos: Se puede cambiar de motor de base de datos sin ningún problema. Las reglas de negocio no deben estar amarradas a esta.
- Independiente de agentes externos: Las reglas de negocio no deben saber nada que este fuera de su contexto.
Características
- La comunicación entre las capas se realiza usando interfaces. Cualquier implementación es provista en tiempo de ejecución.
- Cualquier dependencia externa, como base de datos o servicios web, pertenecen a la capa externa.
- La UI también pertenece a la capa externa.
- Los objetos que representan el negocio pertenecen a las capas internas.
- Las capas externas dependen de las capas internas.
- Las capas internas no pueden depender de las capas externas.
- Todo lo que pueda cambiar se debe encontrar en una capa externa.
Elementos:
El número de elementos puede variar, pero siempre se debe tener en cuenta que el Domain Model es el centro de todo.
- Core: Domain model, servicios, interfaces de repositorio, otras interfaces.
- UI: Mvc, Servicios Web, etc.
- Test: Pruebas unitarias o de integración.
- Infraestructura: Implementación de las interfaces definidas en el Core.
Nota: Para ver un ejemplo práctico les recomiendo leer este post: c# Principios SOLID – Caso práctico: Módulo de seguridad Parte 1
Estilos relacionados:
- The clean architecture: Definida por Robert C. Martin, es la unión de todos los estilos que comparten el mismo principio de no depender de cosas que cambian o pueden cambiar.
- Hexagonal architecture: También conocido como Ports and Adapters, este tipo fue definido por Alistair Cockburn y adoptado por Steve Freeman y Nat Pryce en su libro Growing Object Oriented Software.
Nota: Para aprender más de este estilo les recomiendo leer los 4 post que publico Jeffrey Palermo:
- The Onion Architecture : part 1
- The Onion Architecture : part 2
- The Onion Architecture : part 3
- The Onion Architecture : part 4
Conclusiones:
La arquitectura cebolla fue definida por Jeffrey Palermo en el año 2008 a causa del gran problema que viene con el estilo NCapas que es el acoplamiento innecesario que se genera entre las capas y entre varias responsabilidades de infraestructura. Este estilo de arquitectura no es ideal para aplicaciones pequeñas, pero para aplicaciones con un comportamiento complejo del negocio es recomendable usarlo. Se debe tener en cuenta que este estilo está muy relacionado con el principio SOLID Dependency Inversion. Finalmente, este estilo tiene como principales características que las capas exteriores dependen de las capas interiores, la comunicación entre las capas se hace a través de interfaces y que las aplicaciones que usan este estilo por lo general son fáciles de mantener, probar y sobre todo que se encuentren desacopladas de elementos de infraestructura.
Referencias:
Metal Tip:
Este artículo lo escribí escuchando la canción The Phantom of the opera de la banda Nightwish de Finlandia, les comparto el enlace.
Happy coding and Stay Heavy lml
Code2Read por Luis Aldazabal Gil 
Hola, estaba esperando hace mucho este post. Me gustaría que continuaras explicando esta arquitectura con un ejemplo práctico como hiciste en tus anteriores publicaciones.
¡Saludos!
Me gustaLe gusta a 1 persona
Hola, puedes ir revisando este articulo donde ya vine implementando este estilo: http://code2read.com/2015/03/13/csharp-ood-principios-solid-caso-practico-ood-parte1/.
Gracias
Me gustaMe gusta
Muy bueno Luis. Siempre hay que tener mas de una arquitectura bajo la manga mas que la clasica N-Capas.
Me gustaLe gusta a 1 persona
Muy interesante. Pero de entrada puedo decir que las dependencias no se reducen, tan solo se estan invirtiendo. Y no hablo de inyección de dependencia, que es definitivamente algo bueno, sino del acoplamiento. El acoplamiento sigue y sigue, solo que invertido. El hecho de que la capa de datos dependa de la capa de negocio, en el aspecto de la arquitectura, implica que todo cambio en las reglas de negocio podría requerir un cambio en el modelo de datos. Esto es cierto también en la arquitectura en n-capas, solo que invertido. En todo acoplamiento un cambio en la entidad referenciada puede generar un cambio obligatorio en la entidad que hace la referencia. Entonces estamos ante lo mismo. En las características se manifiesta que : «Todo lo que pueda cambiar se debe encontrar en una capa externa.», sin embargo, la parte mas cambiante es siempre la lógica del negocio, que en la arquitectura cebolla se encuentra en la capa interna. Esos detalles me hacen dudar de las ventajas que pueda otorgarnos la arquitectura cebolla.
Me gustaMe gusta