Este post es parte de una serie de post en ingles de Jeffrey Palermo, en ellos se describe lo que Jeffrey llama la "Arquitectura de Cebolla" - Onion Arquitecture -.
La arquitectura aquí descrita es muy apropiada para aplicaciones de negocio con un amplio ciclo de vida o aplicaciones que tienen un comportamiento complejo. Mediante el énfasis del uso de interfaces para los contratos de comportamiento, se fuerza a la externalizacion de la infraestructura.
Arquitectura tradicional en capas
El diagrama 1, muestra la representación de la arquitectura tradicional en capas. Esta es el tipo de arquitectura básica y mas utilizada. Cada capa inferior depende de la capa superior, y a su vez cada capa va a depender de una infraestructura común y servicios comunes.
Diagrama 1: Arquitectura en capas
La gran desventaja de esta arquitectura de capas de arriba hacia abajo, es que crea acoplamientos fuertes, es decir cada capa es acoplada a las capas inferiores, y cada capa es también acoplada con varias partes de la infraestructura que tienen diferentes preocupaciones. Aunque, sin acoplamiento, nuestros sistemas realmente no harían nada útil, el problema es que esta arquitectura tradicional crea acoplamientos innecesarios.
El problema principal (y también el mas común) es el acoplamiento entre la UI (interface de usuario, por sus siglas en ingles) y la lógica de negocios para acceder a los datos. Sí, la UI esta acoplada con el acceso a datos en esta arquitectura, dependencias transitivas continúan siendo dependencias; la UI no puede funcionar sin la lógica de negocios y la lógica de negocios no puede funcionar sin el acceso a datos; intencionalmente ignoramos la infraestructura, ya que esta puede variar de sistema a sistema.
Las técnicas de acceso a datos cambian frecuentemente, históricamente, la industria a modificado estas técnicas por lo menos cada tres años, por lo tanto, posiblemente en tres años vamos a tener que modificar sistemas sanos, de larga vida que son de misión critica para los negocios. Los sistemas no son actualizados para mantenerse al día, debido a que es muy difícil lograrlo, por lo tanto si el acoplamiento impide el actualizar fácilmente partes del sistema, no queda otra opción que despreciar el sistema y dejar que se convierta en obsoleto. Así es como un sistema heredado - legacy - se congela en el tiempo, y eventualmente es reemplazado por uno nuevo.
Arquitectura de Cebolla
Aquí es donde entra la arquitectura de cebolla, que si bien no es algo nuevo, si se propone este nombre para identificar este patrón arquitectural. Los patrones son útiles debido a que proporciona a los profesionales del software un vocabulario común mediante el cual comunicarse. En la arquitectura de cebolla existen varios aspectos, que si tenemos un termino común para describirlos, entonces nos podemos comunicar eficientemente.
El diagrama 2 muestra esta arquitectura. La parte importante es que controla el acoplamiento; como regla general, todo el código puede depender de capas centrales, pero no puede depender de capas fuera de la capas base - core -. En otras palabras, el acoplamiento se dirige hacia el centro. Esta arquitectura favorece la programación orientada a objetos.
Diagrama 2: Arquitectura de cebolla
En el centro podemos observar el dominio de modelos - Domain model -, que representa la combinación de estado y comportamiento de los modelos a través de la organización. Alrededor del dominio de modelos existen otras capas que incluyen mas cuestiones de comportamiento. El numero de capas de la base de la aplicación puede variar, pero hay que recordar que siempre el domino de modelos esta en el centro y debido a que las capas se acoplan al centro, el dominio de modelos solo puede acoplarse a si mismo.
La primera capa alrededor de nuestro dominio de modelos, es donde típicamente encontramos las interfaces que nos van a proporcionar el comportamiento para guardar u obtener un objeto, esta capa se llama las interfaces de repositorio. El guardar o leer un objeto, no es un comportamiento de la base de la aplicación, ya que típicamente esto es competencia de la base de datos; así que solo la interface con este comportamiento es la que se encuentra en la base de la aplicación.
En las orillas de nuestro diagrama vemos la UI, infraestructura y las pruebas, esto se debe a que la capa exterior es reservada para los artefactos que cambian constantemente; por lo tanto estos deben de ser intencionalmente aislados de la base de la aplicación. Ahí mismo en la orilla nos encontraremos con alguna clase que implemente la interface de repositorio. esta clase va a estar particularmente acoplada al método de acceso a datos, y es por eso que reside fuera de la base. Debido a que esta clase implementa la interface repositorio, esta clase esta acoplada a la interface.
La arquitectura de cebolla se apoya plenamente en el principio de Dependencia Inversa - Dependency Inversion -. La base de la aplicación necesita de la implementación de las interfaces base, y si las clase que las implementas existen en los bordes de la aplicaciones, entonces necesitamos de algún mecanismo que "inyecte" esas clases al momento de ejecución de la aplicación, para que así, haga algo útil.
Un cambio importante es esta arquitectura es, que la base de datos no es el centro, si no un recurso externo. Externalizar la base de datos puede ser un reto para algunas personas que piensan en las aplicaciones como aplicaciones de datos. Con la arquitectura de cebolla, no hay aplicaciones de datos. Pueden existir aplicaciones que podrían hacer uso de las base de datos como un servicio de almacenamiento, pero solo a través de alguna infraestructura externa de código, que implemente las interfaces que hagan sentido para la base de la aplicaciones. Desacoplar las aplicaciones de las bases de datos, sistemas de archivos, etc. minimiza el costo de mantenimiento durante la vida de la aplicación.
Alistar Cockburn ha escrito sobre la arquitectura hexagonal; tanto esta la arquitectura hexagonal como la arquitectura de cebolla comparten la siguiente premisa: Externalizar la infraestructura y escribir un adaptador en código de manera que la infraestructura no tenga un acoplamiento fuerte con la aplicación.
En los siguientes posts se hablara mas detalle acerca de esta arquitectura.
Jeffry Palermo CTO de Headspring Systems en Austin, TX, es ademas MCSD.Net, Microsoft MVP, Scrummmaster certificado, líder del grupo Austin .Net, miembro del consejo AgileAustin, ponente de INETA y mentor de INETA.
La arquitectura aquí descrita es muy apropiada para aplicaciones de negocio con un amplio ciclo de vida o aplicaciones que tienen un comportamiento complejo. Mediante el énfasis del uso de interfaces para los contratos de comportamiento, se fuerza a la externalizacion de la infraestructura.
Arquitectura tradicional en capas
El diagrama 1, muestra la representación de la arquitectura tradicional en capas. Esta es el tipo de arquitectura básica y mas utilizada. Cada capa inferior depende de la capa superior, y a su vez cada capa va a depender de una infraestructura común y servicios comunes.
Diagrama 1: Arquitectura en capas
El problema principal (y también el mas común) es el acoplamiento entre la UI (interface de usuario, por sus siglas en ingles) y la lógica de negocios para acceder a los datos. Sí, la UI esta acoplada con el acceso a datos en esta arquitectura, dependencias transitivas continúan siendo dependencias; la UI no puede funcionar sin la lógica de negocios y la lógica de negocios no puede funcionar sin el acceso a datos; intencionalmente ignoramos la infraestructura, ya que esta puede variar de sistema a sistema.
Las técnicas de acceso a datos cambian frecuentemente, históricamente, la industria a modificado estas técnicas por lo menos cada tres años, por lo tanto, posiblemente en tres años vamos a tener que modificar sistemas sanos, de larga vida que son de misión critica para los negocios. Los sistemas no son actualizados para mantenerse al día, debido a que es muy difícil lograrlo, por lo tanto si el acoplamiento impide el actualizar fácilmente partes del sistema, no queda otra opción que despreciar el sistema y dejar que se convierta en obsoleto. Así es como un sistema heredado - legacy - se congela en el tiempo, y eventualmente es reemplazado por uno nuevo.
Arquitectura de Cebolla
Aquí es donde entra la arquitectura de cebolla, que si bien no es algo nuevo, si se propone este nombre para identificar este patrón arquitectural. Los patrones son útiles debido a que proporciona a los profesionales del software un vocabulario común mediante el cual comunicarse. En la arquitectura de cebolla existen varios aspectos, que si tenemos un termino común para describirlos, entonces nos podemos comunicar eficientemente.
El diagrama 2 muestra esta arquitectura. La parte importante es que controla el acoplamiento; como regla general, todo el código puede depender de capas centrales, pero no puede depender de capas fuera de la capas base - core -. En otras palabras, el acoplamiento se dirige hacia el centro. Esta arquitectura favorece la programación orientada a objetos.
Diagrama 2: Arquitectura de cebolla
La primera capa alrededor de nuestro dominio de modelos, es donde típicamente encontramos las interfaces que nos van a proporcionar el comportamiento para guardar u obtener un objeto, esta capa se llama las interfaces de repositorio. El guardar o leer un objeto, no es un comportamiento de la base de la aplicación, ya que típicamente esto es competencia de la base de datos; así que solo la interface con este comportamiento es la que se encuentra en la base de la aplicación.
En las orillas de nuestro diagrama vemos la UI, infraestructura y las pruebas, esto se debe a que la capa exterior es reservada para los artefactos que cambian constantemente; por lo tanto estos deben de ser intencionalmente aislados de la base de la aplicación. Ahí mismo en la orilla nos encontraremos con alguna clase que implemente la interface de repositorio. esta clase va a estar particularmente acoplada al método de acceso a datos, y es por eso que reside fuera de la base. Debido a que esta clase implementa la interface repositorio, esta clase esta acoplada a la interface.
La arquitectura de cebolla se apoya plenamente en el principio de Dependencia Inversa - Dependency Inversion -. La base de la aplicación necesita de la implementación de las interfaces base, y si las clase que las implementas existen en los bordes de la aplicaciones, entonces necesitamos de algún mecanismo que "inyecte" esas clases al momento de ejecución de la aplicación, para que así, haga algo útil.
Un cambio importante es esta arquitectura es, que la base de datos no es el centro, si no un recurso externo. Externalizar la base de datos puede ser un reto para algunas personas que piensan en las aplicaciones como aplicaciones de datos. Con la arquitectura de cebolla, no hay aplicaciones de datos. Pueden existir aplicaciones que podrían hacer uso de las base de datos como un servicio de almacenamiento, pero solo a través de alguna infraestructura externa de código, que implemente las interfaces que hagan sentido para la base de la aplicaciones. Desacoplar las aplicaciones de las bases de datos, sistemas de archivos, etc. minimiza el costo de mantenimiento durante la vida de la aplicación.
Alistar Cockburn ha escrito sobre la arquitectura hexagonal; tanto esta la arquitectura hexagonal como la arquitectura de cebolla comparten la siguiente premisa: Externalizar la infraestructura y escribir un adaptador en código de manera que la infraestructura no tenga un acoplamiento fuerte con la aplicación.
En los siguientes posts se hablara mas detalle acerca de esta arquitectura.
Jeffry Palermo CTO de Headspring Systems en Austin, TX, es ademas MCSD.Net, Microsoft MVP, Scrummmaster certificado, líder del grupo Austin .Net, miembro del consejo AgileAustin, ponente de INETA y mentor de INETA.
No hay comentarios.:
Publicar un comentario