Archivo por meses: octubre 2012

La importancia de una buena arquitectura

¿Qué es una arquitectura de software y que nos puede ofrecer?
En el área de software, una arquitectura nos identifica los elementos más importantes del mismo, es decir, nos da visibilidad global a todos los pasos a seguir para desarrollar.

¿Por qué es importante? Porque necesitamos una arquitectura para entender el sistema, organizar su desarrollo, plantear la realización del software y hacerlo evolucionar.

En un desarrollo de software se nos plantearán muchas dudas y casuísticas que deberemos saber cómo abordar desde un primer momento. En este planteamiento es muy importante responder a preguntas sencillas… ¿Quién? ¿Cuándo? ¿Cómo? ¿Dónde?… relacionadas con la solución para los requisitos técnicos y operacionales de nuestro sistema. Las respuestas a estas preguntas nos definirán qué componentes forman el sistema, cómo se relacionan y cómo llevan a cabo la funcionalidad.

Es muy importante tener en cuenta que las arquitecturas de software no responden únicamente a requisitos estructurales, sino que están relacionadas con aspectos de rendimiento, usabilidad, reutilización, restricciones tecnológicas e incluso cuestiones estéticas.

Arquitecturas y metodologías
Existen muchas metodologías de desarrollo de software; desde métodos muy pesados a muy ligeros que aparecen cómo respuesta al excesivo formalismo de otros métodos.

En un sistema con casos de uso que definen una secuencia de acciones entre el usuario y el sistema, visto desde un punto de vista arquitectónico, no todos los casos de uso tienen la misma importancia dónde es aconsejable destacar aquellos que nos ayudan a evitar los riesgos más importantes y sobre todo los que representan la funcionalidad básica del sistema que se debe realizar.

Cómo primera fase se debe diseñar una arquitectura base que defina nuestro sistema, lo haga robusto y sobretodo, cumpla la funcionalidad especificada.

!Una arquitectura se debe adaptar siempre a nuestra necesidad, y en ocasiones, una arquitectura puede suponer una penalización a nuestro sistema.

Tipos de arquitecturas
Hoy en día existen muchos tipos de arquitectura y todos ellos aportan su granito de arena. Lo más común en una arquitectura es que se base en un conjunto de tipos para obtener las principales ventajas de cada uno de ellos.

Debemos tener en cuenta que los diferentes tipos de arquitecturas son definiciones abstractas de cómo dividir en partes más pequeñas el sistema y de cómo estas partes deben interactuar entre si.

Cómo citación y mención a las más importantes tenemos: Cliente – Servidor, N-Layer, N-Tier, Orientado a Objetos, Presentación desacoplada, DDD (Domain Driven Design), Orientación a servicios… entre otras.

Hasta aquí todo muy bonito y perfecto… pero… ¿Cómo diseñamos una arquitectura para nuestro sistema de software?

Layers vs. Tiers
Antes de nada se debe distinguir los conceptos de Layers (Capas) y Tiers (Niveles).

El primero de ellos se refiere a desacoplar elementos de forma jerárquica de roles y responsabilidades, proporcionado una separación de las preocupaciones que tenemos en el software sin tener en cuenta la localización física de estos componentes en servidores o diferentes lugares.

El segundo desacopla de forma física los segmentos de estos elementos que se encuentran en diferentes servidores dando cómo resultado un despliegue distribuido proveyendo mejoras de escalabilidad, disponibilidad y utilización de recursos.

Ambos son importantes y se deben tener presentes, pero separar la lógica de nuestro software en N-Layers es importante para nosotros, para el cliente y para nuestro equipo. Nuestras necesidades de IT, nos indicarán si debemos usar N-Tier o no.

Ambas hacen referencia a la que es para mí una gran frase: ¡Divide y vencerás!

Próximos pasos…
En este conjunto de artículos me voy a basar, principalmente, en una arquitectura de N-Layer con orientación al dominio con C#. Esta arquitectura lleva conmigo un par de años y sin duda, me ha proporcionado enormes ventajas en proyectos pequeños, medianos y grandes en su justa medida.

En los próximos artículos iremos definiendo estos pequeños subsistemas de nuestro sistema de software.