Patrones de Arquitectura

Son decisiones de diseño importantes ya tomadas para generar un esquema, estructura o tipo de comunicación entre componentes.

Dominio: Arquitectura de Software.

Patrones monolíticos vs distribuidos

• Monolíticos: En este tipo de patrones, se entiende que existe una comunicación directa entre las partes del sistema, pero al distribuir dicho sistema este funciona como un ente único, esto dificulta la manutención del mismo pues no se pueden alterar partes especificas sin afectar al sistema en su totalidad, sin embargo, se puede desarrollar de manera más rápida.
• Distribuidos: En este caso, el patrón distribuido es aquel que despliega el sistema en forma seccionada, cada uno de los subsistemas funcionan como entes monolíticos de por si, esto facilita la manutención o la alteración de estos subsistemas sin dañar el sistema en su totalidad, sin embargo, se debe tener cuidado de generar inconvenientes de comunicación entre los subsistemas.

Gran Bola de Lodo: Es un patrón que surge del descuido y el caos, aquellos donde no se tomo en cuenta el concepto de arquitectura, ni se tomaron decisiones prudentes, por tanto el sistema queda diseminado sin orden y con una comunicación ineficiente que dificulta su crecimiento.

Modelo Vista Controlador

Modelo-vista-controlador (MVC) es un patrón de arquitectura de software, que separa los datos y la lógica de negocio de una aplicación de su representación y el módulo encargado de gestionar los eventos y las comunicaciones.

Para ello MVC propone la construcción de tres componentes distintos que son el modelo, la vista y el controlador, es decir, por un lado define componentes para la representación de la información, y por otro lado para la interacción del usuario.

Este patrón de arquitectura de software se basa en las ideas de reutilización de código y la separación de conceptos, características que buscan facilitar la tarea de desarrollo de aplicaciones y su posterior mantenimiento.

Capas

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.

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

• Capa de Aplicació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.
• Capa de 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.
• Capa de Datos: Esta capa contiene la lógica de comunicación con otros sistemas que llevan a cabo tareas por la aplicación. Generalmente está representada por una base de datos, que es responsable por el almacenamiento persistente de información.

Orientado a eventos / Provisión de eventos

• Orientado a eventos. Trata sobre cómo conectar componentes a través de eventos. Cada componente publica eventos a un bus de eventos común y los componentes interesados a estos eventos pueden estar suscritos y luego responder al respecto. No hay otra forma de comunicación, el bus de eventos pasa ser el método principal de comunicación entre componentes. Algo complejo es saber si una acción que hicimos tuvo el resultado que esperábamos, en general suelen ser eventualmente consistentes, lo que significa que cuando hacemos una escritura el sistema no nos garantiza que va a estar disponible hasta que ese evento no se distribuya en todas las partes que lo necesita.

• Provisión de eventos. En vez de que nuestra aplicación tenga el estado actual del sitio, podríamos tener solamente guardados los eventos que nos importan.

Microkernel - Plug-ins

Esta arquitectura esta compuesta por 2 componentes, el sistema core y los modulos plug-in. 

El core contiene la minima funcionalidad y los módulos plug-in son componentes autónomos e independientes que contienen procesamiento especializado, características adicionales y código personalizado que está diseñado para mejorar o ampliar el sistema central para producir capacidades empresariales adicionales. 

Generalmente, los módulos plug-in deben ser independientes de otros módulos plug-in, pero ciertamente puede diseñar plug-ins que requieran que otros plug-ins estén presentes. De cualquier manera, es importante mantener la comunicación entre plug-ins a un mínimo para evitar problemas de dependencia.

Cuando leemos esto lo primero que se nos viene a la mente es OSGi, porque este estándar nació para darle soporte a este tipo de arquitecturas y el ejemplo más significativo de esta arquitectura sea eclipse.

Comparte-nada

Compartir recursos entre diferentes componentes agrega mucha complejidad a la hora de decidir prioridades o disponibilidad del componente, entonces se busca crear que NO se tenga punto de unión entre componentes. Esta arquitectura es muy potente al procesar la información ya que al separar los componentes se puede enfocar en el fallo por que cada componente hace uso único de los recursos de dicho sistema.

Microservicios

Patrones de arquitectura micro servicio

Son Componentes distribuidos donde cada componentes va a exponer una funcionalidad al resto del sistema. de esta forma modularizamos el sistema a traes de estos ser. independientes.

Los clientes o los mismos servicios consumen estas funcionalidades entre ellos.

Se debe tener comunicación entre ellos, de forma directa o indirecta (bus de eventos).

CQRS

La segregación de responsabilidades de consultas y comandos (CQRS), Es un estilo de arquitectura que separa las operaciones de lectura de las operaciones de escritura.

Los comandos, deberían basarse en tareas, en lugar de centrarse en datos. (“Reservar habitación de hotel” y no “Establecer ReservationStatus en Reservado”). Los comandos se pueden colocar en una cola para un procesamiento asincrónico, en lugar de que se procesen de forma sincrónica.

Las consultas, nunca modifican la base de datos. Una consulta devuelve un DTO que no encapsula ningún conocimiento del dominio.

Hexagonal - Puertos y adaptadores

La arquitectura hexagonal, Es un estilo de arquitectura que mueve el foco de un programador desde un plano más conceptual hacia la distinción entre el interior y el exterior del software. 

La parte interior son los casos prácticos y el modelo domain está construido sobre ello. 

La parte exterior es UI, base de datos, mensajería, etc. 

La conexión entre el interior y el exterior es mediante puertos, y su implementación equivalente se conocen como adaptadores. Por esta razón, este estilo de arquitectura se conoce habitualmente como Puertos y Adaptadores.

Diseño orientado al dominio

Patrón de arquitectura Diseño orientado al dominio

Guía la aplicación y el diseño a través del uso del lenguaje común entre el negocio y el desarrollo.

Buscar modularizar el sistema a través de contextos delimitados

Notas del Curso Profesional de Arquitectura de Software.