Estilos y patrones arquitectónicos de software

1. Estilos y Patrones Arquitectónicos
Los estilos arquitectónicos incluyen patrones como cliente/servidor, arquitectura en capas,
arquitecturabasadaencomponentes,arquitecturade busmensajesde mensajesyarquitectura
orientada a servicios (SOA). Es importante entender que los estilos describen diferentes
aspectos de las aplicaciones, es por eso que un estiloarquitectónico,también conocido como
un patrón arquitectónico, mejora la partición y promueve la reutilización del diseño,
proporcionando soluciones a problemas recurrentes con frecuencia.
La arquitecturade un sistemade software casi nuncase limitaa unúnico estiloarquitectónico,
pero es a menudo una combinación de estilos arquitectónicos que componen el sistema
completo.
Estilos arquitectónicos
Cliente/Servidor
El estilo cliente/servidor describe los sistemas que implican un cliente independiente y un
sistemade servidor,ademásde unaredde conexióndistribuida,esdecirestoimplicaque varios
clientes accedan directamente a una aplicación de servidor, esto se refiere a un estilo
arquitectónico de 2 niveles.
La arquitectura cliente/servidor es una aplicación que tiene una interfaz de usuario que se
comunicacon un servidor,donde se encuentralabase de datos y donde existe lagranparte de
la lógica de negocio.
Cliente/Servidor describe la relación entre un servidor y varios clientes, donde el cliente inicia
una o más solicitudes mediante una interfaz de usuario y espera la respuesta. El servidor
autorizaal usuarioy luegollevaacaboel procesamientorequeridoparagenerarel resultado.El
servidor puede enviar respuestas utilizandoprotocolosy formatos de datos para comunicar la
información al cliente.
Variaciones:
 Sistemas Cliente-Cola-cliente: Este enfoque permite a los clientes comunicarse con
otros clientes a través de una cola basada en servidor.
 Peer-to-Peer (P2P). Permite que el cliente y el servidor puedan intercambiar sus roles
conel finde distribuirysincronizararchivose informaciónatravésde múltiplesclientes.
 Los servidoresde aplicaciones.Losservidoresejecutanaplicacionesyserviciosparaque
un cliente acceda a través de un navegador.
Beneficios:
 Mayor seguridad: Todos los datos se almacenan en el servidor, que generalmente
ofrece un mayor control de la seguridad de las máquinas cliente.
 Acceso de datos centralizada: Debidoaque los datosse almacenansóloenel servidor,
el accesoycambiosalosdatossonmuchomásfácilesde administrarqueenotrosestilos
arquitectónicos.
 Facilidad de mantenimiento:Rolesy responsabilidadesde unsistemade computación
se distribuyenentre variosservidoresque se conocenentre sía travésde unared. Esto

2. asegura que un cliente no se vea afectado por una reparación de servidores,
actualización o reubicación.
Se considera utilizar el estilo cliente/servidor, si la aplicación se basa en servidor y ayudara a
muchos clientes, por ejemplo aplicaciones basadas en web.
Este estilo es adecuado cuando se desea centralizar el almacenamiento de datos, copias de
seguridad o cuando la aplicación debe ser compatible con diferentes tipos de clientes y
dispositivos. Sin embargo puede afectar a la extensibilidady escalabilidad del sistema, ya que
depende de un servidor central.
Basado en Componentes
Se centraenladescomposicióndeldiseño,encomponentesfuncionalesológicosquepresentan
interfacesde comunicaciónbiendefinidosque contienemétodos,eventosypropiedades.Esto
proporciona un mayor nivel de abstracción de los principios de diseño orientados a objetos.
El principio clave es el uso de componentes que son:
 Reutilizable:Componentesdiseñadosparaser reutilizadosendiferentesescenariosen
diferentes aplicaciones.
 Reemplazable: Los componentes pueden ser sustituidos fácilmente con otros
componentes similares.
 Contextonoespecífico:Loscomponentesestándiseñadosparafuncionarendiferentes
entornos y contextos.
 Extensible:Uncomponente puede extenderseapartirde componentesexistentespara
proporcionar nuevo comportamiento.
 Encapsulado: Componentes exponen interfaces que permiten al usuario utilizar su
funcionalidad, y no revelan detalles de los procesos internos.
 Independiente: Los componentes están diseñados para tener dependencias mínimas
sobre otros componentes.
Beneficios:
 Facilidad de implementación: A medida que nuevas versiones compatibles estén
disponibles, puede reemplazar las versiones existentes, sin impacto en los otros
componentes.
 Coste reducido: El uso de componentes de terceros le permite distribuir el costo de
desarrollo y mantenimiento.
 Facilidadde desarrollo:Los componentesimplementaninterfacesbienconocidaspara
proporcionar funcionalidad definida.
 Reutilizable. El uso de componentes reutilizables.
Estos patrones se utilizan a menudo para construir aplicaciones compuestas que combinan y
reutilizan los componentes a través de múltiples aplicaciones.
Domain Driven Design DDD (Dominio Impulsado al Diseño)
Es un enfoque orientado a objetos para el diseño de software basado en el dominio de la
empresa,para lo cual se debe tenerun buenconocimientodel dominiodel negocioque desea
modelar.El equipode desarrolloamenudotrabajaconexpertosenel dominiode negociopara
modelar el dominio.Los arquitectos, desarrolladores y expertos en la materia tienen diversos

3. orígenes, y en muchos ambientes utilizarán diferentes lenguajes para describir sus objetivos,
diseños y requerimientos. Dentro de Domain Driven Design, todo el equipo se compromete a
utilizar un solo idioma que se centra en el dominio del negocio.
Los problemasde comunicacióndentro de losequiposde desarrollose debennosóloala mala
interpretación del lenguaje del dominio, sino también por el hecho de que el lenguaje del
dominio es en sí mismo ambiguo.
MientrasDomainDrivenDesignofrece muchasventajastécnicas,talescomoel mantenimiento,
se debe aplicar sólo a los dominios complejos donde el modelo y los procesos lingüísticos
proporcionanclarosbeneficiosenlacomunicacióndeinformacióncompleja,yenlaformulación
de un entendimiento común del dominio.
Beneficios:
 Comunicación. Todas las partes dentro de un equipo de desarrollo pueden utilizar el
modelo de dominio.
 Extensible. El modelo de dominio a menudo es modular y flexible, lo que es fácil
actualizar y cambiar los requisitos.
 Comprobable. Los objetos del modelo de dominio, permite que sean más fácilmente
probados.
Considere DDD si tiene un dominio complejo y desea mejorar la comunicación y el
entendimiento dentro de su equipo de desarrollo.
Arquitectura en Capas
Arquitecturaencapasse centra enla agrupaciónde la funcionalidadrelacionadadentrode una
aplicación en distintas capas que se apilan verticalmente en la parte superior de la otra.
La comunicación entre capas, ayuda a mantener una fuerte separación de intereses que,a su
vez, apoya la flexibilidad y facilidad de mantenimiento. Una capa puede interactuar sólo con
componentes en la misma capa o con componentes de la capa directamente debajo de él.
Las capas de una aplicaciónpuedenresidirenel mismoequipofísico(el mismonivel) opueden
estar distribuidos en equipos independientes, y los componentes de cada capa pueden
comunicarse con componentes de otras capas a través de interfaces bien definidas.
Principios comunes:
 Abstracción. Abstrae la vista del sistema,mientras proporciona suficiente detalle para
comprender las funciones y responsabilidades de las capas individuales y la relación
entre ellos.
 La encapsulación.Nohaysuposicionesdebenhacerse sobre lostiposdedatos,métodos
y propiedades.
 Claramente definido capas funcionales. La separación entre la funcionalidad en cada
capa esclara,permite que losdatosfluyantantohaciaarribacomohaciaabajoentre las
capas.
 Alta cohesión.Biendefinidosloslímitesde responsabilidadparacadacapa,ylagarantía
de que cada capa contiene funcionalidad directamente relacionados con las tareas de
esa capa.

4.  Reutilizable. Las capas inferiores no tienen dependencias en las capas más altas,
permitiéndoles ser reutilizable en otros escenarios.
 Acoplamiento débil. La comunicación entre capas se basa en la abstracción y eventos
para proporcionar el acoplamiento débil entre las capas.
La arquitecturaencapas,soportaunaseriede patronesde diseño,ladivisiónde lafuncionalidad
proporciona mayores oportunidades para poner a prueba el comportamiento de los roles
individuales.
Principios fundamentales de los Patrones de presentación separados:
 Separación de preocupaciones. Dividen los procesamientos, la interfaz de usuario en
funciones distintas; por ejemplo, MVC tiene tres funciones:
Modelo: Representa los datos.
Vista: Representa la interfaz de usuario.
Controlador: Manejalas solicitudes,manipula el modelo, y realiza otras operaciones.
 Basada en eventos de notificación. El patrón Observer se utiliza comúnmente para
proporcionar notificaciones a la vista.
 Manejo de eventos delegada. El controlador maneja eventos disparados desde los
controles de interfaz de usuario en la vista.
Beneficios de la arquitectura en capas, y el uso de un patrón Presentación Separado, son:
 Abstracción. Las capas permiten que se hagan cambios en el nivel abstracto.
 Aislamiento. Permite aislar mejoras tecnológicas a capas individuales con el fin de
reducir el riesgo y minimizar el impacto en el conjunto del sistema.
 Manejabilidad. La separación de las preocupaciones centrales ayuda a identificar las
dependencias.
 Rendimiento. La distribución de las capas a través de múltiples niveles físicos puede
mejorar la escalabilidad.
 Reutilización. Roles promueven la reutilización.
 Testabilidad. El aumento de la capacidad de prueba surge de tener interfacesde capa
bien definidos.
Se considere aplicar el estilo arquitectónico en capas si tiene capas existentes que son
adecuados para su reutilización en otras aplicaciones,también es apropiado si su aplicación
debe ser compatible con diferentes tipos de clientes y diferentes dispositivos.
Mensaje de bus
La arquitectura de bus de mensajes describe el principio de la utilización de un sistema de
software que puede recibiry enviarmensajesatravés de uno o más canalesde comunicación,
por loque las aplicacionespuedeninteractuarsinnecesidadde conocerlosdetallesespecíficos
sobre la otra. La interacción entre las aplicaciones se logra mediante el paso de mensajes.
Muchas implementaciones consisten en aplicaciones individuales que se comunican mediante
esquemas comunes y una infraestructura compartida para enviar y recibir mensajes.
Un bus de mensajes proporciona la capacidad de manejar:
 Comunicacionesde mensajesorientados.Toda la comunicaciónentre lasaplicaciones
se basa en mensajes que utilizan esquemas conocidos.

5.  Lógica de procesamiento complejo. Las operaciones complejas se pueden ejecutar
mediante la combinación de un conjunto de operaciones más pequeñas, cada una de
las cuales soporta tareas específicas.
 Las modificacionesa la lógica de procesamiento.Debidoala interaccióncon el bús se
basa en esquemas y comandos comunes.
 Integracióncon diferentesambientes.Mediante el usode unmodelode comunicación
basada en mensajes, se puede interactuar con las aplicaciones desarrolladas para
diferentes entornos.
El diseño proporciona una arquitectura conectable que permite insertar aplicaciones en el
proceso,o mejorarlaescalabilidaduniendovariasinstancias de la misma aplicación en el bús.
Las variaciones en el estilo bus de mensajes incluyen:
 Enterprise Service Bus (ESB). Un ESB suele proporcionarserviciosque transformanlos
mensajes de un formato a otro, permitiendo a los clientes que utilizan formatos de
mensaje incompatibles se comuniquen entre sí.
 Internet Service Bus (ISB). Es similar a un bus de servicios empresariales, pero con
aplicaciones alojadas en la nube en lugar de en una red empresarial.
Beneficios de la arquitectura mensaje-bus son:
 Extensibilidad: Las aplicaciones se pueden agregar o quitar desde el bus sin tener un
impacto en las aplicaciones existentes.
 Baja complejidad: La complejidad de la aplicación se reduce debido a que cada
aplicación sólo necesita saber cómo comunicarse con el bus.
 Flexibilidad: El conjunto de aplicaciones que componen un proceso complejo, o los
patronesde comunicaciónentre lasaplicaciones,se puede cambiarfácilmenteparaque
coincida con los cambios en los requisitos de negocio o usuarios.
 Acoplamientodébil:Nohaydependenciadelaaplicaciónensí,loque permitecambios,
actualizaciones y reemplazos que exponen la misma interfaz.
 Escalabilidad:Variasinstanciasde lamismaaplicaciónse puedenconectaral busconel
fin de manejar múltiples solicitudes al mismo tiempo.
 Simplicidadde aplicación:Cada aplicacióndebesercompatible conunaúnicaconexión
con el bus de mensajes en lugar de múltiples conexiones a otras aplicaciones.
Considere el estilo arquitectónico bus de mensajes si tiene aplicaciones existentes que
interactúanentre sípararealizartareas,osi deseacombinarvariastareasenunasolaoperación,
también es apropiado si está implementando una tarea que requiere la interacción con
aplicaciones externas, o las aplicaciones alojadas en diferentes ambientes.
N-Tier / 3-Tier
N-Capas y 3-Capas estos estilos arquitectónicosde despliegue,describen la separación de la
funcionalidadensegmentosdelamismamaneraque elestiloencapas,peroconcadasegmento
siendo un nivel que puede ser situado en un equipo separado físicamente.
La arquitectura de la aplicación de N-capas se caracteriza por la descomposición funcional de
aplicaciones, componentes de servicio, y su implementación distribuida, ofrece una mayor
escalabilidad, disponibilidad, capacidad de administración y utilización de recursos. Cada nivel
es completamente independiente de todos los otros niveles.

6. La comunicación entre niveles es típicamente asíncrona con el fin de apoyar una mejor
escalabilidad. La arquitectura de N-Capas suelen tener por lo menos tres partes lógicas
separadas,cada uno situadoenunservidorfísicoindependiente. Cadaparte esresponsable de
la funcionalidad específica.
Beneficios de N-tier / 3-tier:
 Mantenibilidad. Debido a que cada nivel es independiente de los otros niveles, las
actualizaciones o cambios pueden llevarse a cabo sin afectar a la aplicación en su
conjunto.
 Escalabilidad. Debido a que los niveles se basan en el despliegue de capas, escalando
una aplicación es relativamente sencilla.
 Flexibilidad. Debido a que cada nivel se puede gestionar o escalar de forma
independiente, se aumenta la flexibilidad.
 Disponibilidad.Permitenel usode componentesfácilmenteescalables,loque aumenta
la disponibilidad.
La arquitectura N-capas o el estilo arquitectónico de 3-capas también es apropiado si desea
compartir la lógica de negocio entre aplicaciones, y si se tiene el hardware suficiente para
asignar el número necesario de servidores para cada nivel. Se considera el uso de sólo tres
niveles si está desarrollando una aplicación de intranet, donde se encuentran todos los
servidores dentro de la red privada.
Orientado a Objetos
La arquitectura orientada a objetos se basa en la división de responsabilidades para una
aplicación. Los objetos son discretos, independiente e imprecisa; se comunican a través de
interfaces, llamandoa métodos a acceder a las propiedades de otros objetos, y mediante el
envío y recepción de mensajes.
Los principios fundamentales de la arquitectura orientada a objetos son:
 Abstracción. Esto le permite reducirunaoperacióncomplejaenunageneralizaciónque
conserva las características básicas de la operación.
 Composición. Los objetos pueden ser ensamblados a partir de otros objetos.
 Herencia. Los objetos pueden heredar de otros objetos, los cambios en el objetobase
se propagan automáticamente a los objetos que heredan.
 La encapsulación. Objetos exponen funcionalidad sólo a través de los métodos, y
ocultan los detalles internos tales como el estado y las variables de otros objetos.
 Polimorfismo.Estole permite anularel comportamientode untipobase que apoyalas
operaciones en su aplicación mediante la aplicación de los nuevos tipos que son
intercambiables con el objeto existente.
 El desacoplamiento.Permite proporcionarimplementacionesalternativassinafectara
los consumidores de la interfaz.
Los principales beneficios de la arquitectura orientada a objetos son:
 Comprensible.Al trazar la aplicaciónmásde cerca a los objetosdel mundoreal,loque
la hace más comprensible.
 Reutilizable. Reutilización a través de polimorfismo y abstracción.
 Comprobable. Mejor capacidad de prueba a través de la encapsulación.

7.  Extensible.Laencapsulación,polimorfismoyabstracciónaseguranque uncambioenla
representación de datos no afecta a las interfaces que el objeto expone.
Se considere aplicar el estilo arquitectónico orientado a objetos, si se desea modelar una
aplicaciónenfunciónde losobjetosdel mundoreal,tambiénesadecuadosi debe encapsularla
lógica y los datos juntos en componentes reutilizables.
Estilos Arquitectónicos Orientados a Servicios
La arquitectura orientada a servicios (SOA) permite la funcionalidad de la aplicación que se
proporcionacomo un conjuntode servicios,ylacreación de aplicacionesque hacenuso de los
serviciosde software. ServiciosenSOA se centranenproporcionarunesquemaylainteracción
basada en mensajes con una aplicación a través de interfaces, no debe ser tratado como un
proveedor de servicio basado en componentes.
Los clientesyotrosserviciospuedenaccederalosservicioslocalesque se ejecutanenel mismo
nivel, o acceder a los servicios remotos a través de una red de conexión.
Los principios fundamentales de la arquitectura SOA son:
 Servicios son autónomas. Cada servicio se mantiene, desarrolla, implementa y es
versionado de forma independiente.
 Los servicios son distribuibles. Los servicios puedenestar ubicados en cualquier parte
de una red, de forma local o remota.
 Losserviciosestándébilmenteacoplados. Cadaservicioesindependiente delosdemás.
 La compatibilidad se basa en la política. La política en este caso significa la definición
de características tales como el protocolo y la seguridad.
Los ejemplos comunes de aplicaciones orientadas a servicios incluyen el intercambio de
información, como los sistemas de reserva y tiendas en línea.
Los principales beneficios de la arquitectura SOA son:
 Alineaciónde dominio. Lareutilizacióndelosservicioscomunesconinterfacesestándar
aumenta las oportunidades de negocio y de tecnología, además reduce los costos.
 Abstracción. Servicios son autónomos.
 Detectabilidad.Los serviciospuedenexponera las descripcionesque permitenaotras
aplicaciones y servicios para localizarlos y determinar automáticamente la interfaz.
 Interoperabilidad. Debido a que los protocolos y formatos de datos se basan en
estándares de la industria, el proveedor y el consumidor del servicio pueden ser
construidos y desplegados en diferentes plataformas.
 Racionalización. En lugar de duplicar la funcionalidad en el número de aplicaciones,
elimina la duplicación.
Se considerar aplicar el estilo SOA si usted tiene acceso a los servicios adecuados que desea
volver a utilizar, este estilo es adecuado cuando se debe apoyar la comunicación basada en
mensajes y exponer la funcionalidad de una manera independiente de la plataforma.