Arquitectura – Cuando nuestro sistema se vuelve una constelación

Estilo constelación
Estilo constelación

Introducción

Se preguntaran ¿Qué tiene que ver una constelación con un sistema?, bueno a continuación les explicaré a que me refiero.

Una constelación está compuesta por miles de estrellas, que al usar la imaginación podemos llegar a formar figuras en el cielo. En Wikipedia podemos encontrar la siguiente definición:

Una constelación, es una agrupación convencional de estrellas, cuya posición en el cielo nocturno es aparentemente invariable. Pueblos, generalmente de civilizaciones antiguas, decidieron vincularlas mediante trazos imaginarios, creando así siluetas virtuales sobre la esfera celeste. 

Constelaciones
Constelaciones

Al igual que una constelación, un sistema está compuesto por componentes (1 o muchos), que si no se controla adecuadamente, en la medida que el sistema va evolucionando, solo podremos descubrir que se quiso hacer usando la imaginación. A este diseño lo domino el Estilo de arquitectura constelación.

Estilo constelación
Estilo constelación

Podrán apreciar en las imágenes de arriba que tienen cosas parecidas, como:

  • Están compuestas por muchos elementos: estrellas o componentes.
  • Existen muchas relaciones entre ellos.
  • Se debe tener mucha paciencia e imaginación para lograr formar las figuras o estilos que representan.

En la siguiente imagen podemos apreciar una arquitectura estilo 3 capas y la constelación Orion ambas fáciles de identificar por su diseño simple.

Constelacion Orion y estilo 3 capas
Constelacion Orion y estilo 3 capas

¿Como llegamos a aplicar el estilo de arquitectura constelación?

Creo que existen muchas formas de llegar a esto sin ningún problema o esfuerzo, este debe ser uno de los estilos de arquitectura más usados en las aplicaciones modernas (SARCASMO). Algunas de las razones por lo que ocurre esto son las siguientes:

  • Cuando la arquitectura no está bien definida
    • ¿Qué estilo de arquitectura se usa?
  • Cuando no se respetan las capas
    • ¿Puedo llamar a la capa de datos desde presentación?
  • Cuando el acoplamiento entre módulos es fuerte y va aumentando.
  • Cuando la arquitectura actual es compleja
    • Si lo hago de esta forma es más sencillo y toma menos tiempos

El desarrollo de la primera fase o versión de un sistema es en la que, normalmente, se tiene más control:

  • Sabemos dónde deben ir las cosas
  • No se cuentan con muchos módulos o aún no se relacionan entre ellos.

A medida que el sistema va creciendo es donde empieza el desorden:

  • Los módulos empiezan a relacionarse entre ellos.
  • No se respetan las capas.
  • Aumenta el acoplamiento.
  • Se crean dependencias cíclicas entre capas.

Este desorden puede aumentar si la persona encargada de hacer los cambios no conoce el sistema. Todo este desorden ocurre cuando la arquitectura propuesta no se deja entender, no soporta fácilmente nuevos requerimientos o es muy complicado agregar algún cambio, cuando llegamos a este punto sabemos que nuestro sistema sufre uno o más de estos design smells:

  • Rígido
  • Frágil
  • inmóvil
  • Viscoso
  • Complejo
  • Repetido
  • Opaco

Evolución del estilo constelación

Veamos el siguiente caso practico:

En la versión 1.0 del sistema tenemos un sitio web con dos módulos: administración y ventas:

Módulo ventas y administración
Versión 1.0

En un mantenimiento que se le hizo al sistema se necesito reutilizar una consulta de administración desde el módulo de ventas:

Módulo ventas y administración unidos
Versión 1.1

Luego en la versión 2.0 se agrega el modulo de facturación que depende del módulo de ventas:

Módulo ventas, facturción y administración
Versión 2.0

En la versión 3.0 se agrega el módulo de almacén que necesita comunicarse con el módulo de facturación:

Versión 3.0
Versión 3.0

En la versión 4.0 todo se deformo, ahora solo se necesite que todo funcione, como sea, pero que funcione:

Versión 4.0
Versión 4.0

¿Cómo podemos solucionar esto?

Para evitar que nuestro sistema termine siendo uno más que aplique este estilo debemos seguir los siguientes principios, patrones y estrategias para reducir el acoplamiento, revertir las dependencias y diseñar mejor los componentes.

Principios de diseño orientado a objetos:
  • SOLID
    • Srp: Single responsability principle
    • Ocp: Open closed principle
    • Lsp: Livkov susbtitution principle
    • Isp: Interface segregación principle
    • Dip: Dependency inversión principle

NOTA: Articulo recomendado: ¿Qué tan SOLID es tu código?

Principios de diseño de paquetes
  • Cohesión
    • REP: The realease/reuse equivalency principle
    • CCP: The common closure principle
    • CRP: The common reuse principle
  • Acoplamiento
    • ADP: The acyclic dependencies principle
    • SDP: The stable dependencies principle
    • SPA: The stable abstraction principle

NOTA: Articulo recomendado: c# Principios de diseño de paquetes

Estrategias de refactorización de arquitectura:
  • Partition Responsibilities
  • Extract Service
  • Introduce decoupling layer
  • Rename Entity
  • Merge functionality
  • Break Cycle
  • Orthogonalize
  • Introduce strict layering
  • Introduce hierarchies
  • Introduce Interceptor hooks
  • Eliminate dependencies by dependency injection
Estilos de arquitectura desacopladas:
Otras técnicas:
  • Patrón Anticorruption layer (ACL)

    Anticorruption Layer
    Anticorruption Layer
  • Bus de mensajería (MessageBus)

    MessageBus
    MessageBus
  • Patrones inyección de dependencias
    • Inyección por constructor
    • Inyección por propiedad
    • Inyección por método

NOTA: Articulo recomendado: ¿Qué estrategias existen para inyectar dependencias?

  • Contenedores de inyección de dependencias
    • Simple Injector
    • Ninject
    • StructureMap
    • Unity

NOTA: Articulo recomendado: IoC ¿Cuándo o cuándo no debemos invertir el control de código?

Conclusiones:

Esta forma de trabajar es más común de lo que creemos, a medida que los sistemas crecen también se empiezan a deformar. Una constelación se aparece a un sistema grande y desordenado en los siguientes puntos: están compuestas por muchos elementos: estrellas o componentes, existen muchas relaciones entre ellos y se debe tener mucha paciencia e imaginación para lograr formar las figuras o entender el estilo que representa. La buena noticia es que existen técnicas, principios y patrones que nos ayudan a romper estas dependencias: principios SOLID, principios de diseño de paquetes, técnicas de refactorización de arquitectura, estilos desacoplados, bus de mensajería, el patrón anticorruption layer y la inyección de dependencias.

Referencias:
Metal Tip:

Este artículo lo escribí escuchando la canción Battery de la banda Metallica de Estados Unidos, les comparto el enlace.

Happy coding and Stay Heavy lml

Anuncios

Un comentario en “Arquitectura – Cuando nuestro sistema se vuelve una constelación

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s