Patrones de arquitectura
La arquitectura de software es la estructura de un sistema, compuesta por los componentes del software, las relaciones entre ellos, y las propiedades de ambos. Se enfoca en cómo se organiza y estructura el sistema completo.
¿Para qué sirve?
- Proporciona una visión global del sistema.
- Facilita la planificación y la toma de decisiones.
- Ayuda a identificar riesgos y definir estrategias de mitigación.
- Mejora la comunicación entre equipos.
- Asegura que el sistema sea escalable, mantenible y eficiente.
-
Videotutoriales:
Lista de Estilos de Arquitectura Comunes y su Interpretación
- Monolítica
- Interpretación: Toda la funcionalidad del software se ejecuta en una única aplicación.
- Microservicios
- Interpretación: La aplicación se divide en servicios pequeños e independientes que se comunican entre sí.
- MVC (Model-View-Controller)
- Interpretación: Divide la aplicación en tres componentes principales: modelo, vista y controlador.
- MVVM (Model-View-ViewModel)
- Interpretación: Similar a MVC, pero con una capa adicional (ViewModel) para la vinculación de datos.
- SOA (Service-Oriented Architecture)
- Interpretación: Los componentes del software proporcionan servicios a otros componentes a través de un protocolo de comunicación.
- Event-Driven Architecture
- Interpretación: Los componentes del software se comunican a través de la generación, detección y consumo de eventos.
Ejemplos de patrones arquitectónicos incluyen los siguientes:
- Programación por capas [1]
- Tres niveles
- Pipeline
- Invocación implícita
- Arquitectura en pizarra
- Arquitectura dirigida por eventos, Presentación-abstracción-control
- Peer-to-peer
- Arquitectura orientada a servicios
- Objetos desnudos
- Modelo Vista Controlador
Dominios en el diseño de Patrones
- Control de acceso. Hay muchas situaciones en las cuales el acceso a datos, características y funcionalidad son limitadas a la definición de los usuarios. Desde un punto de vista arquitectónico, acceder a determinadas partes del software debe tener un riguroso control.
- Concurrencia. Muchas aplicaciones deben manejar múltiples tareas de forma que simule el paralelismo. Hay muchas formas de manejar esta concurrencia y cada una puede ser presentada por un patrón arquitectónico diferente.
- Distribución. El problema de distribución dirige el problema de forma en que los sistemas o componentes se comunican con otros en un entorno distribuido. El patrón más común para afrontar el problema es the broker. Actuando como un middleman entre el componente cliente y el servidor. El cliente envía un mensaje al broker y éste se encarga de completar la conexión.
- Persistencia. Los datos persistentes son almacenados en bases de datos o archivos y pueden ser leídos o modificados por otros procesos más adelante. En los entornos orientados a objetos esto va más allá y lo que puede ser accedido o modificable son las propiedades de los objetos.
Programación por capas
La programación por capas es un modelo de desarrollo software en el que el objetivo primordial es la separación (desacoplamiento) de las partes que componen un sistema software o también una arquitectura cliente-servidor: lógica de negocios, capa de presentación y capa de datos. De esta forma, por ejemplo, es sencillo y mantenible crear diferentes interfaces sobre un mismo sistema sin requerir cambio alguno en la capa de datos o lógica.
La ventaja principal de este estilo es que el desarrollo se puede llevar a cabo en varios niveles y, en caso de que sobrevenga algún cambio, solo afectará al nivel requerido sin tener que revisar entre el código fuente de otros módulos, dado que se habrá reducido el Acoplamiento informático hasta una interfaz de paso de mensajes.
Además, permite distribuir el trabajo de creación de una aplicación por
niveles; de este modo, cada grupo de trabajo está totalmente abstraído del resto de niveles, de forma que basta con conocer la API que existe entre niveles.
En el diseño de sistemas informáticos actual se suelen usar las arquitecturas multinivel o programación por capas. En dichas arquitecturas a cada nivel se le confía una misión simple, lo que permite el diseño de arquitecturas escalables (que pueden ampliarse con facilidad en caso de que las necesidades aumenten).
El más utilizado actualmente es el diseño en tres niveles (o en tres capas).
Capas y niveles
- Capa de presentación: la que ve el usuario (también se la denomina «capa de usuario»), presenta el sistema al usuario, le comunica la información y captura la información del usuario en un mínimo de proceso (realiza un filtrado previo para comprobar que no hay errores de formato). También es conocida como interfaz gráfica y debe tener la característica de ser «amigable» (entendible y fácil de usar) para el usuario. Esta capa se comunica únicamente con la capa de negocio.
- Capa de negocio: es donde residen los programas que se ejecutan, se reciben las peticiones del usuario y se envían las respuestas tras el proceso. Se denomina capa de negocio (e incluso de lógica del negocio) porque es aquí donde se establecen todas las reglas que deben cumplirse. Esta capa se comunica con la capa de presentación, para recibir las solicitudes y presentar los resultados, y con la capa de datos, para solicitar al gestor de base de datos almacenar o recuperar datos de él. También se consideran aquí los programas de aplicación.
- Capa de datos: es donde residen los datos y es la encargada de acceder a los mismos. Está formada por uno o más gestores de bases de datos que realizan todo el almacenamiento de datos, reciben solicitudes de almacenamiento o recuperación de información desde la capa de negocio.
Todas estas capas pueden residir en un único ordenador, si bien lo más usual es que haya una multitud de ordenadores en donde reside la capa de presentación (son los clientes de la arquitectura cliente/servidor). Las capas de negocio y de datos pueden residir en el mismo ordenador, y si el crecimiento de las necesidades lo aconseja se pueden separar en dos o más ordenadores. Así, si el tamaño o complejidad de la base de datos aumenta, se puede separar en varios ordenadores los cuales recibirán las peticiones del ordenador en que resida la capa de negocio.
Si, por el contrario, fuese la complejidad en la capa de negocio lo que obligase a la separación, esta capa de negocio podría residir en uno o más ordenadores que realizarían solicitudes a una única base de datos. En sistemas muy complejos se llega a tener una serie de ordenadores sobre los cuales corre la capa de negocio, y otra serie de ordenadores sobre los cuales corre la base de datos.
En una arquitectura de tres niveles, los términos «capas» y «niveles» no significan lo mismo ni son similares.
El término «capa» hace referencia a la forma como una solución es segmentada desde el punto de vista lógico:
- Presentación. (Conocida como capa Web en aplicaciones Web o como capa de usuario en Aplicaciones Nativas)
- Lógica de Negocio. (Conocida como capa Aplicativa)
- Datos. (Conocida como capa de Base de Datos)
En cambio, el término «nivel» corresponde a la forma en que las capas lógicas se encuentran distribuidas de forma física. Por ejemplo:
- Una solución de tres capas (presentación, lógica del negocio, datos) que residen en un solo ordenador (Presentación+lógica+datos). Se dice que la arquitectura de la solución es de tres capas y un nivel.
- Una solución de tres capas (presentación, lógica del negocio, datos) que residen en dos ordenadores (Presentación+lógica por un lado; lógica+datos por el otro lado). Se dice que la arquitectura de la solución es de tres capas y dos niveles.
....