Capítulo 3: Los patrones arquitectónicos y estilos

¿Qué es un estilo arquitectónico?

También llamado un patrón arquitectónico, es un conjunto de principios: un patrón de grano grueso que
proporciona un marco abstracto para una familia de sistemas. Un estilo arquitectónico que mejora la
separación y promueve la reutilización del diseño, proporcionando soluciones a los problemas recurrentes
con frecuencia.

La comprensión de los estilos arquitectónicos proporciona varios beneficios. El beneficio más importante
es que proporcionan un lenguaje común. También proporcionan oportunidades para conversaciones que
son la tecnología agnóstica. Esto facilita un mayor nivel de conversación que se incluyen todos los patrones
y principios, y sin entrar en detalles.

Resumen de estilos arquitectónicos clave

 Servidor de cliente: Segrega el sistema en dos aplicaciones, donde el cliente realiza solicitudes al
servidor. En muchos casos, el servidor es una base de datos con la lógica de aplicación
representado como procedimientos almacenados.
 Arquitectura basada en componentes: Se descompone el diseño de aplicaciones en componentes
funcionales o lógicos reutilizables que exponen bien definidos interfaces de comunicación.
 Domain Driven DesignUn estilo de arquitectura orientada a objetos centra en el modelado de un
dominio de negocio y la definición de objetos de negocio basados en entidades dentro del ámbito
empresarial.
 Arquitectura en capas: Particiones las preocupaciones de la aplicación en grupos apilados (capas).
 Bus de mensajes: Un estilo de arquitectura que prescribe el uso de un sistema de software que
puede recibir y enviar mensajes a través de uno o más canales de comunicación, por lo que las
aplicaciones puedan interactuar sin necesidad de conocer detalles específicos acerca de uno al
otro.
 N-Tier / 3-Tier: Segrega funcionalidad en segmentos separados de la misma manera como el estilo
en capas, pero con cada segmento de ser un nivel situado en un equipo separado físicamente.
 Orientado a objetos: Un paradigma de diseño basado en división de responsabilidades para una
aplicación o sistema en objetos reutilizables y autosuficientes individuales, cada uno que contiene
los datos y el comportamiento pertinentes al objeto.
 Arquitectura orientada al servicio (SOA:) Se refiere a las aplicaciones que exponen y consumen
funcionalidad como un servicio mediante contratos y mensajes.

Combinando Estilos arquitectónicos

La arquitectura de un sistema de software casi nunca se limita a un único estilo arquitectónico, pero es a
menudo una combinación de estilos arquitectónicos que componen el sistema completo.
Hay muchos factores que influyen en los estilos arquitectónicos que decide. Estos factores incluyen la
capacidad de su organización para el diseño e implementación; las capacidades y la experiencia de sus
promotores; y su infraestructura y limitaciones de la organización. Las siguientes secciones le ayudarán a
determinar los estilos apropiados para sus aplicaciones.
Cliente / Servidor estilo arquitectónico
Describe sistemas que implican un cliente independiente y sistema de servidor, y una red de conexión
distribuida.
En términos más generales, sin embargo, el estilo de arquitectura cliente / servidor describe la relación
entre un cliente y uno o más servidores, donde el cliente inicia una o más solicitudes (tal vez usando una
interfaz de usuario gráfica), espera a las respuestas, y procesa las respuestas en el recibo. El servidor
normalmente autoriza al usuario y luego lleva a cabo el procesamiento requerido para generar el resultado.
El servidor puede enviar las respuestas utilizando una serie de protocolos y formatos de datos para
comunicar la información al cliente

Los principales beneficios de la / arquitectura cliente-servidor son:

 mayor seguridad. Todos los datos se almacenan en el servidor, que ofrece en general un mayor
control de la seguridad de las máquinas cliente.
 acceso de datos centralizada. Dado que los datos sólo se almacenan en el servidor, el acceso y
actualizaciones de los datos son mucho más fáciles de administrar que en otros estilos
arquitectónicos.
 Facilidad de mantenimiento. Los roles y responsabilidades de un sistema de computación se
distribuyen entre varios servidores que se conocen entre sí a través de una red. Esto asegura que
un cliente permanece inconsciente y no afectado por una reparación de servidores, actualización,
o la reubicación.

Basado en componentes estilo arquitectónico

Se centra en la descomposición del diseño en componentes funcionales o lógicos individuales que exponen
interfaces de comunicación bien definidos que contienen métodos, eventos y propiedades. Esto
proporciona un mayor nivel de abstracción que los principios de diseño orientado a objetos, y no se centra
en cuestiones tales como protocolos de comunicación y estado compartido.
El principio clave del estilo basado en componentes es el uso de componentes que son:

 reutilizable. Los componentes son generalmente diseñados para ser reutilizados en diferentes
escenarios en diferentes aplicaciones.
 Reemplazable. Los componentes se pueden sustituir fácilmente con otros componentes similares.
 No contexto específico. Los componentes están diseñados para operar en diferentes entornos y
contextos.
 Extensible. Un componente puede ser extendido a partir de componentes existentes para
proporcionar un nuevo comportamiento.
 encapsulado. Componentes exponen interfaces que permiten a la persona que llama a utilizar su
funcionalidad, y no revelan detalles de los procesos internos o cualquier variables internas o
estado.
 Independiente. Los componentes están diseñados para tener dependencias mínimos sobre otros
componentes.

Los tipos comunes de los componentes utilizados en aplicaciones incluyen componentes de interfaz de
usuario tales como las redes y los botones, y componentes auxiliares y de servicios públicos que exponen
a un subconjunto específico de funciones utilizadas en otros componentes.
Los siguientes son los principales beneficios de la arquitectura basada en componentes:

 Facilidad de implementación. A medida que nuevas versiones compatibles estén disponibles,

puede reemplazar las versiones existentes, sin impacto en los otros componentes o el sistema en
su conjunto.
 Costo reducido. El uso de componentes de terceros le permite distribuir el costo de desarrollo y
mantenimiento.
 Facilidad de desarrollo. Componentes implementan interfaces bien conocidas para proporcionar
funcionalidad definida, lo que permite el desarrollo sin afectar otras partes del sistema.
 reutilizable. El uso de componentes reutilizables significa que pueden ser utilizados para difundir
el desarrollo y el costo de mantenimiento a través de varias aplicaciones o sistemas.
 Mitigación de complejidad técnica. mitigar la complejidad mediante el uso de un contenedor de
componentes y de sus servicios.
Dominio determinadas por el diseño arquitectónico de estilo
Dominio Driven Design (DDD) es un enfoque orientado a objetos para el diseño de software basado en el
dominio del negocio, sus elementos y comportamientos, y las relaciones entre ellos. Su objetivo es permitir
que los sistemas de software que son una realización del dominio de negocio subyacente mediante la
definición de un modelo de dominio se expresa en el lenguaje de los expertos en el dominio de negocio.
Con el fin de ayudar a mantener el modelo como una construcción del lenguaje puro y útil, se debe aplicar
por lo general una gran cantidad de aislamiento y encapsulado dentro del modelo de dominio. En
consecuencia, un sistema basado en dominio determinadas por el diseño puede venir en un costo
relativamente alto.
Los principales beneficios del estilo Domain Driven Design son:

 Comunicación. Todas las partes dentro de un equipo de desarrollo pueden utilizar el modelo de
dominio y las entidades que define para comunicar conocimientos y necesidades utilizando un
lenguaje de dominio de negocio común de negocios, sin que se requiera la jerga técnica.
 Extensible. El modelo de dominio a menudo es modular y flexible, por lo que es fácil de actualizar
y ampliar las condiciones y requisitos cambian.
 comprobable. Los objetos del modelo de dominio son débilmente acoplados y cohesiva, lo que les
permite ser probados más fácilmente.

Considere DDD si tiene un dominio complejo y desea mejorar la comunicación y el entendimiento dentro
de su equipo de desarrollo, o en el que debe expresar el diseño de una aplicación en un lenguaje común
que todos los interesados puedan entender. DDD también puede ser un enfoque ideal si usted tiene
grandes y complejos escenarios de datos de la empresa que son difíciles de manejar utilizando otras
técnicas.

Estilo Arquitectónico en capas

La arquitectura en capas se centra en la agrupación de funcionalidades relacionadas dentro de una

aplicación en distintas capas que se apilan verticalmente una encima de la otra. La funcionalidad dentro de
cada capa está relacionada por un rol o responsabilidad común y la comunicación entre estas es explícita y
está ligeramente acoplada.

El estilo arquitectónico en capas se describe como una pirámide de reutilización invertida en la que cada
capa agrega las responsabilidades y abstracciones de la capa directamente debajo de ella. Las capas de una
aplicación pueden residir en la misma computadora física (el mismo nivel) o pueden distribuirse en
computadoras separadas y los componentes en cada capa se comunican con componentes en otras capas
a través de interfaces bien definidas.

Los principios comunes para los diseños que utilizan el estilo arquitectónico en capas incluyen: Abstracción,
Encapsulación, Capas funcionales claramente definidas, Alta cohesión, Reusable y Bajo acoplamiento.

Varios patrones de diseño admiten el estilo arquitectónico en capas. Por ejemplo, los patrones de
presentación separada abarcan un rango de patrones que manejan las interacciones del usuario desde la
interfaz de usuario, la presentación y la lógica de negocios, y los datos de la aplicación con los que trabaja
el usuario. Los siguientes son los principios clave de los patrones de presentación separados:

 Separación de intereses: Los patrones de presentación separados dividen las preocupaciones del
procesamiento de la interfaz de usuario en roles distintos, por ejemplo, el patrón MVC tiene tres
roles: el Modelo, la Vista y el Controlador.
 Notificación basada en eventos: El patrón Observer se usa comúnmente para proporcionar
notificaciones a la Vista cuando cambian los datos administrados por el Modelo.
 Gestión delegada de eventos: El controlador maneja los eventos activados desde los controles de
UI en la Vista.
Los principales beneficios del estilo arquitectónico en capas y el uso de un patrón de presentación separada
son: Abstracción, Aislamiento, Manejabilidad, Performance, Reusabilidad y Testabilidad

Estilo Arquitectónico de Bus de Mensajes

Describe el principio de utilizar un sistema de software que puede recibir y enviar mensajes usando uno o
más canales de comunicación, de modo que las aplicaciones puedan interactuar sin necesidad de conocer
detalles específicos entre sí. Es un estilo para el diseño de aplicaciones donde la interacción entre
aplicaciones se logra pasando mensajes a través de un bus común. Un bus de mensajes proporciona la
capacidad de manejar:

 Comunicaciones orientadas a mensajes: Toda comunicación entre aplicaciones se basa en

mensajes que usan esquemas conocidos.
 Lógica de procesamiento complejo: Las operaciones complejas se pueden ejecutar combinando un
conjunto de operaciones más pequeñas, cada una de las cuales admite tareas específicas.
 Modificaciones a la lógica de procesamiento: Debido a que la interacción con el bus se basa en
esquemas y comandos comunes, se puede insertar o eliminar aplicaciones en el bus para cambiar
la lógica que se utiliza para procesar los mensajes.
 Integración con diferentes entornos: Al utilizar un modelo de comunicación basado en mensajes y
basado en estándares comunes, puede interactuar con aplicaciones desarrolladas para diferentes
entornos.

Los diseños de bus de mensajes proporcionan una arquitectura conectable que le permite insertar
aplicaciones en el proceso, o mejorar la escalabilidad al conectar varias instancias de la misma aplicación
al bus. Las variaciones en el estilo del bus de mensajes incluyen:

 Bus de servicios empresariales (ESB): Utiliza servicios para la comunicación entre el bus y los
componentes conectados a este.
 Bus de servicio de Internet (ISB): Uso de identificadores uniformes de recursos (URI) y políticas
para controlar el enrutamiento de la lógica a través de aplicaciones y servicios en la nube.

Los principales beneficios del estilo arquitectónico del bus de mensajes son: Extensibilidad, Baja
complejidad, Flexibilidad, Bajo acoplamiento, Escalabilidad y Simplicidad de aplicación.

Estilo arquitectónico de N-Tier / 3-Tier

La arquitectura de la aplicación N-tier se caracteriza por la descomposición funcional de las
aplicaciones, los componentes de servicio y su implementación distribuida, proporcionando escalabilidad,
disponibilidad, capacidad de administración y utilización de recursos mejoradas. Cada nivel es
completamente independiente de todos los demás niveles, excepto los inmediatamente superiores e
inferiores. La comunicación entre niveles suele ser asíncrona para soportar una mejor escalabilidad.
Las arquitecturas de nivel N normalmente tienen al menos tres partes lógicas separadas, cada una ubicada
en un servidor físico separado. Cada parte es responsable de la funcionalidad específica. Cuando se utiliza
un enfoque de diseño en capas, se despliega una capa en un nivel si más de un servicio o aplicación depende
de la funcionalidad expuesta por la capa.
Los principales beneficios del estilo arquitectónico N-tier / 3-tier son:
 Mantenibilidad.
 Escalabilidad.
 Flexibilidad.
 Disponibilidad.
Considere el estilo arquitectónico de nivel N o de 3 niveles si los requisitos de procesamiento de
las capas de la aplicación difieren de tal manera que el procesamiento en una capa pueda absorber
suficientes recursos para retardar el procesamiento en otras capas o si los requisitos de seguridad de las
capas en la aplicación difieren.
Estilo Arquitectónico Orientado a Objetos
Un diseño orientado a objetos ve un sistema como una serie de objetos que cooperan, en lugar
de un conjunto de rutinas o instrucciones de procedimiento. Los objetos son discretos, independientes y
ligeramente acoplados; se comunican a través de interfaces, llamando a métodos o accediendo a
propiedades en otros objetos, y enviando y recibiendo mensajes. Los principios clave del estilo
arquitectónico orientado a objetos son:
 Abstracción.
 Composición.
 Herencia.
 La encapsulación.
 Polimorfismo.
 Desacoplamiento.
Los principales beneficios del estilo arquitectónico orientado a objetos son los siguientes:
 Comprensible.
 Reutilizable.
 Comprobable.
 Extensible.
 Altamente cohesivo.
Estilo arquitectónico orientado al servicio:
La arquitectura orientada a servicios (SOA) permite que la funcionalidad de la aplicación se
proporcione como un conjunto de servicios y la creación de aplicaciones que utilicen servicios de software.
Los servicios están ligeramente acoplados porque utilizan interfaces basadas en estándares que se pueden
invocar, publicar y descubrir. Los clientes y otros servicios pueden acceder a los servicios locales que se
ejecutan en el mismo nivel o a los servicios remotos mediante una red de conexión.

Los principios clave del estilo arquitectónico SOA son:

Los servicios son:

 Autónomos: Cada servicio es desarrollado independientemente.

 Distribuibles: Se pueden ubicar en cualquier lugar de una red, local o remotamente.
 Ligeramente acoplados: Cada servicio puede ser reemplazado o actualizado sin romper las
aplicaciones que lo utilizan.
 Comparten esquema y contrato, no clase: Cuando se comunican, no con clases internas.
 La compatibilidad se basa en la política: transporte, protocolo y seguridad.
Beneficios:

 Lineación de dominios: La reutilización de servicios.

 Abstracción: Los servicios son autónomos y se accede a través de un contrato formal.
 Descubrimiento: de otras aplicaciones y servicios mediante descripciones.
 Interoperabilidad: El proveedor y el consumidor del servicio se pueden construir y desplegar en
diferentes plataformas.
 Racionalización: Los servicios pueden ser granulares con el fin de proporcionar funcionalidad
específica.

El estilo SOA es adecuado cuando:

 Debe soportar la comunicación basada en mensajes entre segmentos de la aplicación.

 Desea aprovechar los servicios federados, como la autenticación, o exponer servicios detectables
mediante directorios y ser utilizados por clientes sin conocimiento previo de las interfaces.