Arquitectura de software

La arquitectura de Software

Todos los desarrolladores tenemos clara la importancia de disponer de una buena Arquitectua de Software.

Vuelve a leer la frase anterior.

¿Estás de acuerdo? ¿de verdad? ¿De verdad todos los desarrolladores tienen clara esta importancia?

Es más, ¿Piensas que todos los desarrolladores coincidirían en definir qué es una Arquitectura Software? ¿Y en qué consiste una ‘buena’ arquitectura? ¿en qué criterios hay que tener en cuenta para distinguir una buena arquitectura de una mala?.

Permiteme que lo dude. Y mucho.

Vamos a intentar primero ponernos de acuerdo en qué es lo que queremos decir cuando hablamos de Arquitectura en el Software.

No creas que leyendo la correspondiente entrada de Wikipedia queda del todo claro el concepto. Sí que podemos obtener una idea intuitiva de que se trata de una disciplina que se basa en la utilización de distintos patrones para resolver diferentes problemáticas comunes en el desarrollo de productos Software.

Tal como lo veo yo, la Arquitectura de Software es una forma de organizar el código fuente que tienda a minimizar problemas durante las fases de desarrollo, despliegue y, sobre todo, mantenimiento del Sistema.

El diseño y la elección de una determinada Arquitectura de Software no es un proceso separado del resto del desarrollo del proyecto. Al contrario, la elección y/o el diseño de una determinada Arquitectura de Software ES DESARROLLO DE SOFTWARE. Un arquitecto es, o debería ser, un desarrollador. Sí, uno con experiencia y conocimientos que le permitan aplicar soluciones preestablecidas a problemas típicos de la Ingeniería del Software, pero al fin y al cabo, un desarrollador.

Una buena arquitectura permite adelantarse a problemas como:

  • Realizar una división del Sistema en componentes de tal modo que sea sencillo dividir el trabajo de desarrollo entre distintos desarrolladores o incluso distintos equipos. Y hacerlo minimizando el esfuerzo requerido para la integración de dichos componentes.
  • Poder realizar un despliegue del Sistema en cualquier momento y de forma sencilla. Idealmente realizando un único paso.
  • Minimizar el coste de mantenimiento del Sistema, al proporcionar una clara estructuración del código, un a serie de estándares y patrones reconocibles.
  • Con el mismo objetivo del punto anterior, minimizar el impacto al modificar partes no esenciales del sistema (Por ejemplo, el Sistema de almacenamiento, o el tipo de servidor utilizado).

La Arquitectura de Software no se preocupa de si el Sistema funciona correctamente o no. De si ofrece el resultado esperado o no. Se ocupa de la estructura del sistema.

Y el problema de la estructura es bastante más importante que el del comportamiento en un Sistema Software. Un Software que no funcione correctamente pero esté bien estructurado, será sencillo de modificar. Sin embargo, si el sistema funciona perfectamente pero su estructura es mala, será difícil de mantener y poco flexible ante posibles cambios.

Todo Sistema Software ofrece una determinada lógica de negocio que está soportada por los detalles de la implementación. La elección/diseño de una arquitectura debería tratar de dar forma al sistema de manera que la lógica de negocio destaque como la parte esencial del sistema, mientras que los detalles de implementación deberían de ser lo más independientes posibles de esa lógica de negocio. Por ejemplo, la elección de una determinada Base de Datos es un detalle de implementación y un equipo de desarrollo debería ser capaz de desarrollar la lógica de negocio sin conocer nada de este detalle.

De esta manera, además, se posibilita que a lo largo del tiempo sea posible cambiar determinados detalles de implementación sin que esto afecte a la lógica de negocio, haciendo que el cambio sea poco traumático.

Para mí, este es un buen criterio para determinar si una determinada arquitectura es adecuada para un proyecto: Que la lógica de aplicación esté lo mejor desacoplada posible de los detalles de implementación.

Hay ejemplo de arquitecturas típicas que resuelven problemas comunes a distintos tipos de Sistema Software: Arquitectura cliente-servidor, arquitecturas por capas, MVC (Modelo-vista-controlador), aquitectura hexagonal… Pero el propósito de este artículo no es de entrar en detalles de ninguna arquitectura en concreto, sino de analizar qué problema se intenta resolver al elegir/diseñar una de ellas.

Comparte

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *