Patrones de Arquitectura de Software

El concepto de Arquitectura de Software tiene mucho tiempo de antigüedad, pero no fue hasta la década de los 90 que comenzó a utilizarse de manera formal; del mismo modo, analizando los sistemas se observó que existen patrones que se repiten conformando lo que se conoce como estilos arquitectónicos (un patrón es un modelo que podemos seguir para realizar algo, surgen de la experiencia de seres humanos de tratar de lograr ciertos objetivos).

Un patrón de arquitectura de software describe un problema particular y recurrente del diseño, que surge en un contexto específico, y presenta un esquema genérico y probado de su solución.

Un estilo arquitectónico define un conjunto de familias de patrones de software con una determinada estructura y restricciones.

Los patrones de arquitectura están orientados a representar los diferentes elementos que componen una solución de software y las relaciones entre ellos. A diferencia de los patrones de diseño de software que están orientados a objetos y clases (patrones creacionales, estructurales, de comportamiento, de interacción, etc.), los patrones de arquitectura están a un mayor nivel de abstracción.

Los patrones de arquitectura forman parte de la llamada Arquitectura de Software (arquitectura lógica de un sistema), que de forma resumida comprende:

El diseño de más alto nivel de la estructura del sistema
Los patrones y abstracciones necesarios para guiar la construcción del software de un sistema
Los fundamentos para que analistas, diseñadores, programadores, beta testers, etc. trabajen en una línea común que permita cubrir restricciones y alcanzar los objetivos del sistema
Los objetivos del sistema, no solamente funcionales, sino de mantenimiento, auditoría, flexibilidad e interacción con otros sistemas
Las restricciones que limitan la construcción del sistema acorde a las tecnologías disponibles para su implementación

La arquitectura de software define, de manera abstracta, los componentes que llevan a cabo alguna tarea de proceso de información, sus interfaces y la comunicación entre ellos. Toda arquitectura debe ser implementable en una arquitectura física, que consiste simplemente en determinar qué ordenador tendrá asignada cada tarea.

Existen al menos tres vistas absolutamente fundamentales en cualquier arquitectura:

La visión estática: describe qué componentes tiene la arquitectura
La visión funcional: describe qué hace cada componente
La visión dinámica: describe cómo se comportan los componentes a lo largo del tiempo y como interactúan entre sí

El patrón de arquitectura debe contener de alguna manera, información para que estas tres vistas fundamentales estén presentes y puedan servir para la implementación de soluciones basadas en él.

Arquitectura MVC

MVC significa Modelo, Vista y Controlador. MVC separa la aplicación en tres componentes: modelo, vista y controlador.

Modelo : El modelo representa la forma de los datos y la lógica comercial. Mantiene los datos de la aplicación. Los objetos del modelo recuperan y almacenan el estado del modelo en una base de datos.

El modelo es una lógica de datos y negocios.

Ver : la vista es una interfaz de usuario. Visualice los datos de visualización utilizando el modelo para el usuario y también les permite modificar los datos.

La vista es una interfaz de usuario.

Controlador : el controlador maneja la solicitud del usuario. Normalmente, el usuario interactúa con la vista, que en el caso de la solicitud de URL apropiada, esta solicitud será manejada por un controlador. El controlador visualiza la vista adecuada con los datos del modelo como una respuesta.

El controlador es un manejador de solicitudes.

La siguiente figura ilustra el flujo de la solicitud del usuario en ASP.NET MVC.

Según la figura anterior, cuando el usuario ingresa una URL en el navegador, va al servidor y llama al controlador apropiado. Luego, el Controlador usa la Vista y el Modelo apropiados y crea la respuesta y la envía de nuevo al usuario. Veremos los detalles de la interacción en las próximas secciones.


USO EN APLICACIONES WEB:

Aunque originalmente MVC fue desarrollado para aplicaciones de escritorio, ha sido ampliamente adaptado como arquitectura para diseñar e implementar aplicaciones web en los principales lenguajes de programación. Se han desarrollado multitud de frameworks, comerciales y no comerciales, que implementan este patrón (ver apartado siguiente "Frameworks MVC"); estos frameworks se diferencian básicamente en la interpretación de como las funciones MVC se dividen entre cliente y servidor.

Los primeros frameworks MVC para desarrollo web planteaban un enfoque de cliente ligero en el que casi todas las funciones, tanto de la vista, el modelo y el controlador recaían en el servidor. En este enfoque, el cliente manda la petición de cualquier hiperenlace o formulario al controlador y después recibe de la vista una página completa y actualizada (u otro documento); tanto el modelo como el controlador (y buena parte de la vista) están completamente alojados en el servidor. Como las tecnologías web han madurado, ahora existen frameworks como JavaScriptMVC, Backbone o jQuery​ que permiten que ciertos componentes MVC se ejecuten parcial o totalmente en el cliente.

ARQUITECTURA POR CAPAS

El Patrón de arquitectura por capas es una de las técnicas más comúnes que los arquitectos de software utilizan para dividir sistemas de software complicados. Al pensar en un sistema en términos de capas, se imaginan los principales subsistemas de software ubicados de la misma forma que las capas de un pastel, donde cada capa descansa sobre la inferior. En este esquema la capa más alta utiliza varios servicios definidos por la inferior, pero la ultima es inconsciente de la superior. Además, normalmente cada capa oculta las capas inferiores de las siguientes superiores a esta.

Los beneficios de trabajar un sistema en capas son:

– Se puede entender una capa como un todo, sin considerar las otras.
– Las capas se pueden sustituir con implementaciones alternativas de los mismos servicios básicos
– Se minimizan dependencias entre capas.
– Las capas posibilitan la estandarización de servicios
– Luego de tener una capa construida, puede ser utilizada por muchos servicios de mayor nivel.
La imagen que se muestra a continuación presenta el esquema de una arquitectura siguiendo este patrón:

A continuación se describen las tres capas principales de un patrón de arquitectura por capas:

1. Capa de Presentación: Referente a la interacción entre el usuario y el software. Puede ser tan simple como un menú basado en líneas de comando o tan complejo como una aplicación basada en formas. Su principal responsabilidad es mostrar información al usuario, interpretar los comandos de este y realizar algunas validaciones simples de los datos ingresados.

2. Capa de Reglas de Negocio (Empresarial): También denominada Lógica de Dominio, esta capa contiene la funcionalidad que implementa la aplicación. Involucra cálculos basados en la información dada por el usuario y datos almacenados y validaciones. Controla la ejecución de la capa de acceso a datos y servicios externos. Se puede diseñar la lógica de la capa de negocios para uso directo por parte de componentes de presentación o su encapsulamiento como servicio y llamada a través de una interfaz de servicios que coordina la conversación con los clientes del servicio o invoca cualquier flujo o componente de negocio.

3. Capa de Datos: Esta capa contiene la lógica de comunicación con otros sistemas que llevan a cabo tareas por la aplicación. Estos pueden ser monitores transaccionales, otras aplicaciones, sistemas de mensajerías, etc. Para el caso de aplicaciones empresariales, generalmente esta representado por una base de datos, que es responsable por el almacenamiento persistente de información. Esta capa debe abstraer completamente a las capas superiores (negocio) del dialecto utilizado para comunicarse con los repositorios de datos (PL/SQL, Transact-SQL, etc.).

ARQUITECTURA DE MICROSERVICIOS

Los microservicios son un sistema de desarrollo software que en los últimos años ha gozado de una gran popularidad. Aunque muchos se ven atraídos por ellos, no todos se han atrevido a ponerlos en práctica. De hecho, en estos momentos es cuando una gran mayoría de desarrolladores descubren cómo los microservices influyen de manera positiva en aspectos como el tiempo, rendimiento o la estabilidad de proyectos.

Los microservicios o microservices proponen su propia arquitectura.
Características comunes de los microservicios

Hasta ahora, hemos comprobado que los microservices no actúan de manera estándar. A pesar de ello, encontramos unas características comunes.
Características de su software: Puedes ser descompuesto en diferentes partes independientes. Por ello cada uno de los servicios puede ser desplegado y modificado sin afectar a otros aspectos funcionales de la aplicación.
Características de su organización: La manera en la que están organizados supone un contraste con el entorno monolítico. Ya que tienen en cuenta aspectos como las capacidades, necesidades y preferencias del negocio o cliente donde será implantado. En cuanto, a la arquitectura, se usan módulos multifuncionales consiguiendo la creación de un módulo común para todos ofreciendo un servicio en concreto. Sin duda, la gran ventaja es el ahorro de tiempo y la comodidad en tareas de mantenimiento evitando que, al revisar un módulo, el resto del equipo no pueda completar su jornada.
Características de su arquitectura: Cada módulo es independiente ya que, cada uno de ellos cuenta con su propia base de datos, es decir, no acuden todos a la misma. Así evitamos la sobrecarga y la caída de la aplicación.
Características de sus sistemas de aviso y actuación: Al estar varios servicios comunicados necesitamos contar con sistemas de aviso y actuación por si se registrara algún fallo de estos servicios. Es decir, nos daría una advertencia, envío de un mail a soporte, etc. Este sistema es positivo ya que favorece a una buena gestión entre los módulos funcionales restantes.
Ventajas y desventajas de los microservicios

Ahora ya sabemos qué son los microservices así como su arquitectura y características principales. Por ello, vamos a detallar algunas de sus ventajas y desventajas.

Ventajas:

1. Equipo de trabajo mínim
2. Escalabilidad
3. Funcionalidad modular, módulos independientes.
4. Libertad del desarrollador de desarrollar y desplegar servicios de forma independiente
5. Uso de contenedores permitiendo el despliegue y el desarrollo de la aplicación rápidamente

Desventajas

1. Alto consumo de memoria
2. Necesidad de tiempo para poder fragmentar distintos microservicios
3. Complejidad de gestión de un gran número de servicios
4. Necesidad de desarrolladores para la solución de problemas como latencia en la red o balanceo de cargas
5. Pruebas o testeos complicados al despliegue distribuido

Arquitectura Monolítica

Las aplicaciones empresariales modernas, en general, están construidas sobre tres componentes o capas:

• UI - una capa de aplicación cliente o presentación, que es la que maneja la interface con el usuario y que consiste normalmente en páginas HTML/Javascript que se ejecutan en el navegador del usuario; 
• App - una capa de aplicación servidor, que es la que contiene las funcionalidades de negocio, sobre un servidor de aplicaciones.
• DB - una capa de acceso a la base de datos la cual contiene tablas manejadas por un gestor de base de datos, generalmente relacional;

   


Modelo de referencia

Los siguientes serán los componentes que vamos a necesitar en una arquitectura de microservicios:

• Servidor de configuración central

Este componente se encargará de centralizar y proveer remotamente la configuración a cada microservicio. Esta configuración se mantiene convencionalmente en un repositorio Git, lo que nos permitirá gestionar su propio ciclo de vida y versionado.
Servicio de registro / descubrimiento

Este servicio centralizado será el encargado de proveer los endpoints de los servicios para su consumo. Todo microservicio se registrará automáticamente en él en tiempo de bootstrap.

• Balanceo de carga (Load balancer)

Este patrón de implementación permite el balanceo entre distintas instancias de forma transparente a la hora de consumir un servicio.

• Tolerancia a fallos (Circuit breaker)

Mediante este patrón conseguiremos que cuando se produzca un fallo, este no se propague en cascada por todo el pipe de llamadas, y poder gestionar el error de forma controlada a nivel local del servicio donde se produjo.

• Servidor perimetral / exposición de servicios (Edge server)

Será un gateway en el que se expondrán los servicios a consumir.
Centralización de logs

Se hace necesario un mecanismo para centralizar la gestión de logs. Pues sería inviable la consulta de cada log individual de cada uno de los microservicios.

Adicionalmente, también son interesantes los dos siguientes componentes:

• Servidor de Autorización

Para implementar la capa de seguridad (recomendable en la capa de servicios API)

• Monitorización

Es interesante el poder disponer de mecanismos y algún dashboard para monitorizar aspectos de los nodos como, salud, carga de trabajo.

ARQUITECTURA DE MVP

MVP es un patrón arquitectónico de interfaz de usuario diseñada para facilitar pruebas de unidad automatizada y mejorar la separación de inquietudes en lógica de presentación:
El modelo es una interfaz que define los datos que se mostrará o no actuado en la interfaz de usuario.
El presentador actúa sobre el modelo y la vista. Recupera datos de los repositorios (el modelo), y los formatea para mostrarlos en la vista.
La vista es una interfaz pasiva que exhibe datos (el modelo) y órdenes de usuario de las rutas (eventos) al presentador para actuar sobre los datos.


Puede parecer muy ingrato de parte de nuestros usuarios, pero a ellos solo les interesa que nuestra aplicación sea fácil de manejar, rápida y que no tenga errores. Todo lo que hagamos en las capas que ellos no ven, no tiene importancia, mientras no falle…
Crear una interface que sea fácil de usar y que sea intuitiva (termino de moda) resulta en muchas horas de programación, para dejarla a punto







BIBLIOGRAFIA

https://codigofacilito.com/articulos/mvc-model-view-controller-explicado

http://www.tutorialsteacher.com/mvc/mvc-architecture

http://tareasuniversitarias.com/patrones-de-arquitectura-de-software.html

http://jmaw.blogspot.pe/2011/04/h2-margin-bottom-0.html

https://arevalomaria.wordpress.com/2010/12/02/introduccion-al-patron-de-arquitectura-por-capas/

http://www.chakray.com/que-son-los-microservicios-definicion-caracteristicas-y-ventajas-y-desventajas/

http://sergiomaurenzi.blogspot.pe/2015/04/microservicios-parte-i.html

http://enmilocalfunciona.io/arquitectura-microservicios-1/