¿Qué es la arquitectura de software?

Capítulo 1
¿Qué es la Arquitectura de Software?
Arquitectura de la aplicación de software es el proceso de definición de una solución
estructuradaque cumple contodoslosrequisitostécnicosyoperativos,al tiempoque optimiza
la calidad común atributos tales como el rendimiento, la seguridad y capacidad de
administración.Se trata de una serie de decisionesbasadasenuna ampliagama de factores,y
cada una de estasdecisionespueden tenerunimpactoconsiderable enlacalidad,rendimiento,
facilidad de mantenimiento, y en general el éxito de la aplicación.
Philippe Kruchten,GradyBooch, Kurt Bittner,y Rich Reitmanderivany refinadounadefinición
de la arquitecturabasada en el trabajo de Mary Shaw y David Garlan (Shaw y Garlan 1996). Su
definición es:
"Arquitectura de software abarca el conjunto de decisionesimportantes sobre la organización
de un sistemade software que incluye laselecciónde laestructural elementosysusinterfaces
por el cual el sistema está compuesto; comportamiento como especificado en la colaboración
entre dichoselementos;composiciónde éstosestructural y elementosde comportamientoen
subsistemasmásgrandes;yunestiloarquitectónicoque guíaestaorganización. Arquitecturade
software también incluye funcionalidad, usabilidad, flexibilidad, rendimiento, reutilización,
comprensibilidad, económica y limitaciones tecnológicas, compensaciones y preocupaciones
estéticas”.
En Los patrones de la arquitectura empresarial Aplicación, Martin Fowler describe algunos
temasrecurrentescomunesalahorade explicarlaarquitectura.Él identificaestostemascomo:
"El desglose de más alto nivel de un sistema en sus partes; las decisiones que sean difícil de
cambiar;hay múltiplesarquitecturasenunsistema;loque esarquitectónicamentesignificativo
puede cambiar durante la vida de un sistema;y,al final,la arquitecturase reduce a lo que sea
lo importante es”.
En Arquitectura de Software en la práctica (segunda edición),Bass, Clements y Kazman definir
la arquitectura de la siguiente manera:
"La arquitectura de software de un sistema o programa de computación es la estructura o
estructuras del sistema, que comprenden elementos de software, lo visible externamente
propiedadesde esoselementos,ylas relacionesentre ellos.Laarquitecturaes de que se trate
con el ladopúblicode interfaces;detallesprivadosde loselementosDetallesque tiene que ver
exclusivamente con la aplicación interna no-son arquitectónica".
¿Por qué es importante arquitectura?
Al igual que cualquierotraestructuracompleja, elsoftwaredebe serconstruidosobre unabase
sólida.Noconsiderarescenariosclave,ensu defectoa diseñarpara los problemascomunes,o
ensu defectoparaapreciarlas consecuencias alargoplazode lasdecisionesclave puede poner
su aplicación en riesgo. Herramientas y plataformas modernas ayudan a simplificar la tarea de
creaciónde aplicaciones,peronoreemplazanlanecesidadde diseñarlaaplicaciónconcuidado,
basado en sus escenarios y requerimientos específicos. Los riesgos expuestos por la mala
arquitecturaincluyensoftware que esinestable,noescapaz de soportarlos requerimientosde
negocios existentes o futuros, o es difícil de implementar o gestionar en un entorno de
producción.

Los sistemas deben ser diseñados con la consideración para el usuario, el sistema (la TI
infraestructura), y los objetivos de negocio. Para cada una de estas áreas, debe tener un
esquema escenarios clave e identifican importantes atributos de calidad (por ejemplo, la
fiabilidad y escalabilidad) y áreas clave de la satisfacción y la insatisfacción. Siempre que sea
posible, desarrollar y considerar las métricas que miden el éxito en cada una de estas áreas.
Compensacionessonprobables,yunsaldoa menudodebe encontrarse entre losrequisitosde
la competenciaa travésde estas tres áreas.Por ejemplo,laexperienciageneral del usuariode
lasoluciónesmuyamenudounafuncióndel negocioylainfraestructurade TI,yloscambiosen
uno u otro puede afectar significativamente la experiencia del usuario resultante. Del mismo
modo, los cambios en los requisitos de experiencia de usuario pueden tener un impacto
significativo sobre los requisitos de infraestructura de negocio y de TI. Rendimiento podría ser
un importante objetivo del usuario y de negocios, pero el administrador del sistema puede no
ser capaz de invertirenel hardware necesarioparacumplirconese objetivo 100 por cientodel
tiempo.Unpuntode equilibriopodríaserlade alcanzar lametasóloel 80porcientodel tiempo.
Arquitectura se centra en cómo los principales elementos y componentes dentro de una
aplicación son utilizados por, o interactuar con otros elementos y componentes más
importantes dentro de la aplicación. La selección de estructuras de datos y algoritmos o la
implementación detalles de los componentes individuales son preocupaciones de diseño.
Arquitectura y diseño preocupaciones muy a menudo se superponen. En lugar de utilizar las
reglas duras y rápidas para distinguir entre la arquitectura y el diseño, que tiene sentido para
combinar estas dos áreas. En algunos casos, las decisiones son claramente más arquitectónica
enla naturaleza.En otroscasos, lasdecisionessonmássobre el diseño,ycómoayudana darse
cuenta de que la arquitectura.
Siguiendo los procesos descritos en esta guía, y el uso de la información que Contiene, usted
será capaz de construir soluciones arquitectónicas que abordan todos las preocupaciones
pertinentes, se pueden implementar en su infraestructura elegido, y proporcionan resultados
que cumplan con las metas y objetivos originales.
Considere las siguientes preocupaciones de alto nivel cuando se piensa en la arquitectura de
software:
 ¿Cómo van los usuarios a utilizar la aplicación?
 ¿Cómo afectará la aplicación se desplegará en la producción y logró?
 ¿Cuáles son los requisitos de atributos de calidad de la aplicación, tales como la
seguridad, rendimiento, concurrencia, la internacionalización y la configuración?

 ¿Cómo puede la aplicación se ha diseñado para ser flexible y fácil de mantener en el
tiempo?
 ¿Cuáles son las tendencias arquitectónicas que puedan afectar su solicitud ahora o
después se ha implementado?
Los Objetivos de la Arquitectura
Arquitecturade la aplicaciónbuscaconstruirun puente entre losrequerimientosdel negocioy
losrequisitostécnicosmediantelacomprensiónde loscasosde uso y,acontinuación,encontrar
formas de implementar esos casos de uso en el software. El objetivo de la arquitectura es
identificar los requisitos que afectan a la estructura de la aplicación. La buena arquitectura
reduce los riesgos de negocio asociados con la construcción de una solución técnica. Un buen
diseñoessuficientemente flexibleparasercapaz de manejarladerivanatural que se producirá
con el tiempoenhardware y tecnologíade software,así como en escenariosynecesidadesde
losusuarios.Un arquitectodebe tenerencuentael efectogeneral de las decisionesde diseño,
las compensaciones inherentes entre los atributos de calidad (como el rendimiento y la
seguridad), y las compensaciones necesarias para abordar usuario, el sistema y los
requerimientos del negocio.
Tenga en cuenta que la arquitectura debe:
 Exponer la estructura del sistema, pero esconder los detalles de implementación.
 Darse cuenta de todos los casos de uso y escenarios.
 Tratar de responder a las necesidades de los diversos grupos de interés.
 Manejar los requisitos funcionales y de calidad.
El paisaje arquitectónico
Es importante entenderlasfuerzasclavequeestán dandoformaalasdecisionesarquitectónicas
hoy en día, y que va a cambiar la forma en las decisiones de arquitectura se hizo en el futuro.
Estas fuerzas fundamentales son impulsadas por la demanda del usuario, así como por la
demandade las empresas pararesultadosmásrápidos,mejorsoporte paravariarlos estilosde
trabajo y flujos de trabajo, y la mejora de adaptabilidad de diseño de software.
Considere las siguientes tendencias clave:
 Capacitación del usuario. Un diseño que apoya la capacitación del usuario es flexible,
configurable, y se centró en la experiencia del usuario. Diseñe su aplicación con los
niveles adecuados de personalización de usuario y opciones en mente. Permitir al
usuariodefinirlaforma enque interactúancon su aplicación enlugar de dictar a ellos,
pero no sobrecargarlos con opciones innecesarias y ajustes que pueden dar lugar a
confusión.Comprenderlosescenariosclaveyque seanlomássimpleposible; hazlofácil
de encontrar información y utilizar la aplicación.
 La madurez del mercado. Tome ventajade la madurezdel mercado,aprovechandolas
opcionesde plataformaytecnologíaexistentes.Basarse enlosentornosde aplicaciones
de altonivel donde tiene sentido,de modoque ustedpuedacentrarse en lo que es un
valorúnicoensuaplicaciónenvezdecrearalgoque yaexisteyse puedevolverautilizar.
Los patronesde uso que proporcionanuna rica fuente de solucionesprobadasparalos
problemas comunes.

 Diseño flexible. Cada vez más, los diseños flexibles se aprovechan de la articulación
flexible para permitir la reutilización y para mejorar la mantenibilidad. Diseños
conectados permiten proporcionar extensibilidad posterior a la implementación.
Tambiénpuede tomarventajade lastécnicasde orientaciónde serviciotalescomoSOA
para proporcionar interoperabilidad con otros sistemas.
 Las tendencias futuras. Cuando la construcción de su arquitectura, comprende las
tendenciasdel futuroquepodríanafectarsudiseñodespuésde laimplementación.Por
ejemplo, considere las tendencias de la rica interfaz de usuario y los medios de
comunicación,modelosde composicióntalescomomashups,aumentandoel anchode
banda de la red y disponibilidad, uso creciente de dispositivos móviles, la mejora
continuaen el rendimientodel hardware,el interésenlosmodelosde la comunidady
la edición personal, el aumento de la computación basada en la nube y operación
remota.
Los Principios de Arquitectura
El pensamientoactual sobrelaarquitecturasupone quesu diseñovaaevolucionarconel tiempo
y que no se puede saber todo lo que necesita saber por adelantado con el fin de arquitecto
completamente su sistema. Su diseño será generalmente necesitan evolucionar durante las
etapas de implementación de la aplicación a medida que aprende más, y como se prueba el
diseño frente a los requisitos del mundo real. Cree su arquitectura con esta evolución en la
mente de modo que será capaz de adaptarse a los requerimientos que no son totalmente
conocidos en el inicio del proceso de diseño.
Considere las siguientes preguntas a medida que crea un diseño arquitectónico:
 ¿Cuálessonlaspartesfuncionalesde laarquitecturaque representanelmayorriesgosi
consigues que están equivocados?
 ¿Cuáles son las partes de la arquitectura que tienenmás probabilidades de cambiar, o
cuya diseñar puede retrasar hasta más tarde con poco impacto?
 ¿Cuáles son sus supuestos clave, y cómo le probarlos?
 ¿Qué condiciones pueden requerir de refactorización del diseño?
No trate de más de la ingeniería de la arquitectura, y no hacer suposiciones que no se puede
verificar.Ensu lugar,mantenersusopcionesabiertasparael cambiofuturo.Habráaspectosde
sudiseñoque usteddebe fijaral iniciodelproceso,que puedenrepresentarse requiereun costo
significativode rediseño.Identificarestasáreasrápidamentee invertirel tiemponecesariopara
hacerlo bien.
Principios Arquitectura clave
Tenga en cuenta los siguientes principios clave en el diseño de su arquitectura:
 Construir para cambiar en vez de construir para durar. Considere que puede necesitar
la aplicación para cambiar con el tiempo para hacer frente a las nuevas exigencias y
desafíos, y construir en la flexibilidad para apoyar esto.
 Modelo para analizar y reducir el riesgo. Utilice las herramientas de diseño, sistemas
como el modelado Unified Modeling Language (UML), y las visualizaciones en su caso

para ayudar a capturar requerimientos y decisiones arquitectónicas y de diseño, y
analizarsu impacto.Sin embargo,no formularel modelo enla medidaenque suprime
la capacidad de iterar y adaptar el diseño fácilmente.
 Usar modelos y visualizaciones como herramienta de comunicación y colaboración.
Comunicación eficiente del diseño,las decisionesque toma, y los cambios en curso en
el diseño, es fundamental para la buena arquitectura. Usar modelos, vistas y otras
visualizaciones de la arquitectura para comunicar y compartir su diseño eficiente con
todaslaspartesinteresadas,yparapermitirunarápidacomunicaciónde loscambiosen
el diseño.
 Identificar las decisiones clave de ingeniería. Utilice la información de esta guía para
comprender las decisiones de ingeniería clave y las áreas donde los errores se dieron
mása menudo.Invertirenconseguirque estasdecisionesclavebienla primeravezpara
que el diseño es más flexible y menos probable que se rompa por los cambios.
Considere el usode un enfoque incremental e iterativopara refinarsuarquitectura.Comience
con unaarquitecturade referenciaparaobtenerlaimagenderechagrande,yluegoevolucionar
arquitecturascandidatascomo pruebaiterativoy mejorarsu arquitectura.No trate de hacerlo
todo bien desde el principio-diseño tiempotanto como sea posible con el fin de empezar a
probar el diseño frente a los requisitosy supuestos. Añadir Iterativamente detalles al diseñoa
travésde múltiplespasesparaasegurarse deque ustedobtenga lasgrandesdecisionesderechas
primero y, a continuación, centrarse en los detalles. Un error común es bucear en los detalles
demasiado rápidamente y obtener las grandes decisiones equivocadas al hacer suposiciones
incorrectas, o al no evaluar la arquitectura de su eficacia. Al probar su arquitectura, considere
las siguientes preguntas:
 ¿Qué suposiciones he hecho en esta arquitectura?
 Lo explícita o implícita requisitos es esta reunión arquitectura?
 ¿Cuáles son los principales riesgos con este enfoque de arquitectura?
 ¿Qué medidas se han adoptado para mitigar los riesgos clave?
 ¿De qué maneraes estaarquitecturaunamejoraconrespectoa lalíneade base o de la
última arquitectura candidato?

Capítulo 2: Principios fundamentales de Arquitectura de Software
Visión de conjunto
En este capítulo, usted aprenderá acerca de los principios de diseño clave y pautas para la
arquitecturade software. Arquitecturade softwarese describeamenudocomolaorganización
o estructura de un sistema, donde el sistema representa una colección de componentes que
realizan una función o conjunto de funciones específicas. En otras palabras, la arquitectura se
centra en la organización de los componentes para soportar la funcionalidad específica. Esta
organización de la funcionalidad se refiere a menudo como componentes de agrupación en
"áreas de interés". Figura 1 ilustra la arquitectura de aplicaciones común con componentes
agrupados por diferentes áreas de preocupación.
Figura 1
Arquitectura de la aplicación Común
Además de la agrupación delos componentes, otras áreas de interés se centran en la interacción entre
los componentes y cómo los diferentes componentes trabajan juntos.Las directrices deeste capítulo se
examinan las diferentes áreas de interés que usted debe considerar en el diseño de la arquitectura de su
aplicación.
Principios de diseño clave
En nuestros primeros pasos con su diseño, tenga en cuenta los principios clave que le ayudarán a crear
una arquitectura que se adhiere a los principios probados , minimiza los costos y los requisitos de
mantenimiento, y promueve la facilidad de uso y extensibilidad. Los principios fundamentales son:

 Separación de preocupaciones. Divida la aplicación en características distintas con tan poco
solapamiento en funcionalidad como sea posible. El factor importante es la minimización delos
puntos de interacción para lograr una alta cohesión y bajo acoplamiento. Sin embargo, la
separación de funciones en los límites equivocadas puede resultar en alta acoplamiento y
complejidad entre las características a pesar de que la funcionalidad contenida dentro de una
función no se superponen de manera significativa.
 Principio de responsabilidad individual. Cada componente o módulo deben ser responsables
por sólo una característica específicao funcionalidad, o agregación de funcionalidad cohesiva.
 Principio de Conocimiento menos (también conocida como la Ley de Deméter o LoD). Un
componente u objeto no deben saber acerca de los detalles internos de otros componentes u
objetos.
 No te repitas (DRY). Sólo es necesario especificar la intención en un solo lugar. Por ejemplo, en
términos de diseño de la aplicación, funcionalidad específica se debe implementar en un solo
componente; la funcionalidad no debe ser duplicada en ningún otro componente.
 Minimizar el diseño inicial. Sólo diseñar lo que es necesario. En algunos casos, es posible que
necesite diseño integral inicial y las pruebas si el costo de desarrollo o un fallo en el diseño es
muy alta.En otros casos,especialmentepara el desarrollo ágil,puede evitar grandes adelantado
diseño (BDUF). Si sus requisitos de aplicación no son claras, o si hay una posibilidad de que el
diseño evolucionando con el tiempo, evitar hacer un esfuerzo de diseño de gran forma
prematura. Este principio se conoce a veces como YAGNI ("No vas a necesitarlo").
En el diseño de una aplicación o sistema, el objetivo de un arquitecto de software es minimizar la
complejidad separando el diseño en diferentes áreas de interés. Por ejemplo, la interfazde usuario (IU),
el procesamiento de los negocios, y el acceso de todos los datos representan diferentes áreas de
preocupación. Dentro de cada zona,los componentes que el diseño debe centrarseen esa área específica
y no se deben mezclar código de otras áreas deinterés. Por ejemplo, los componentes de procesamiento
de la interfaz de usuario no deben incluir código que accede directamente a una fuente de datos, sino
que debe utilizar cualquiera de los componentes de negocio o componentes de acceso a datos para
recuperar los datos.
Sin embargo, también debe hacer una determinación de costo / valor de la inversión querealicepara una
aplicación.En algunos casos,puede ser necesario simplificar laestructura para permitir,por ejemplo, los
datos de la interfaz de usuario se une a un conjunto de resultados. En general, trate de considerar los
límites funcionales desdeun punto de vista delos negocios también. Las siguientes pautas dealto nivel le
ayudarán a considerar la amplia gama de factores que pueden afectar la facilidad de diseño,
implementación, despliegue, pruebas y mantenimiento de su aplicación.
Prácticas de Diseño
 Mantenga patrones de diseño consistente dentro de cada capa. Dentro de una capa lógica,
cuando sea posible, el diseño de los componentes debe ser coherente para una operación
particular.Por ejemplo, si usted elige utilizar el patrón de la tabla de datos de puerta de enlace
para crear un objeto que actúa como puerta de entrada a las tablaso vistasen una basededatos,
no debe incluir otro patrón como repositorio,que utiliza un paradigma diferente para acceder a
datos e inicializar entidades empresariales. Sin embargo, es posible que necesite utilizar
diferentes modelos para las tareas en una capa que tiene una gran variación en los requisitos,
como por ejemplo una aplicación que contiene las transacciones de negocio y la funcionalidad
de informes.
 No duplique la funcionalidad dentro de una aplicación. Debe haber sólo un componente que
proporciona una funcionalidad específica, esta funcionalidad no debe ser duplicada en ningún
otro componente. Esto hace que los componentes de su cohesión y hace que sea más fácil para
optimizar los componentes Si una característica o funcionalidad cambios específicos. La

duplicación de funcionalidad dentro de una aplicación puede hacer que sea difícil de
implementar cambios, disminuir la claridad, e introducir inconsistencias potenciales.
 Prefiero composición a la herencia. Siempre que sea posible, utilizar la composición sobre la
herencia al reutilizar la funcionalidad ya la herencia aumenta la dependencia entre clases de
padres e hijos,lo que limita la reutilización declases hijas. Esto también reduce las jerarquías de
herencia, los cuales pueden llegar a ser muy difícil de tratar.
 Establecer un estilo de codificación y la convención de nomenclatura para el
desarrollo. Compruebe si la organización ha establecido codificación estilo y estándares de
nomenclatura. Si no, usted debe establecer normas comunes. Esto proporciona un modelo
consistente que hace que sea más fácil para los miembros del equipo de revisión decódigo que
no escriben, lo que conduce a un mejor mantenimiento.
 Mantener la calidad del sistema de control de calidad utilizando técnicas automatizadas
durante el desarrollo. Utilice la unidad de pruebas y otras técnicas de análisis de calidad
automatizado, como el análisis de la dependencia y el análisis de código estático, durante el
desarrollo. Definir métricas claras de comportamiento y rendimiento para los componentes y
subsistemas,y utilizar las herramientas decontrol de calidad automatizados duranteel proceso
de construcción para asegurar que el diseño o implementación de las decisiones locales no
afectan negativamente a la calidad general del sistema.
 Considere la operación de su aplicación. Determinar qué métricas y datos operativos son
requeridos por la infraestructura de TI para garantizar el despliegue eficaz y el funcionamiento
de la aplicación. El diseño de los componentes de su aplicación y los subsistemas con un claro
entendimiento de sus necesidades operativas individuales aliviará significativamente el
despliegueglobal y funcionamiento. Utilicelas herramientas decontrol decalidad automatizados
durante el desarrollo para asegurar que los datos operativa correcta es proporcionada por los
componentes de su aplicación y los subsistemas.
Capas de Aplicación
 Separar las áreas de preocupación. Divida su aplicación en distintas características que se
superponen en funcionalidad lo menos posible.El principal beneficio deesteenfoque es que una
característica o funcionalidad pueden optimizarseindependientemente de otras características
o funcionalidad. Además, si una característica no, no va a causar otras características fallen
también, y que puede funcionar de forma independiente el uno del otro. Este enfoque también
ayuda a hacer la aplicación más fácil deentender y de diseño,y facilita lagestión delos sistemas
interdependientes complejas.
 Sea explícito acerca de cómo las capas se comunican entre sí. Permitiendo que cada capa en
una aplicación para comunicarse con o tener dependencias a todos los de las otras capas se
traducirá en una solución que es más difícil deentender y manejar. Tomar decisiones explícitas
acerca de las dependencias entre capas y el flujo de datos entre ellos.
 Utilice la abstracción para implementar acoplamiento débil entre las capas. Esto se puede
lograr mediantela definición decomponentes de la interfaztales como una fachadacon entradas
y salidas bien conocidos que se traducen peticiones en un formato entendido por los
componentes dentro de la capa. Además, también puede utilizar los tipos de interfaz o clases
base abstractas para definir una interfaz común o abstracción compartida (dependencia
inversión) que debe ser implementado por componentes de la interfaz.
 No mezcle diferentes tipos de componentes en la misma capa lógica. Comience por identificar
diferentes áreas de interés, y luego los componentes del grupo asociados a cada área de
preocupación en capas lógicas. Por ejemplo, la capa de interfaz de usuario no debe contener
componentes de procesamiento de los negocios,sino que debe contener componentes usados
para manejar las solicitudes de entrada del usuario y de usuario proceso.
 Mantenga el formato de datos consistente dentro de una capa o componente. Mezcla de
formatos de datos hará que la aplicación más difícil deimplementar, ampliar y mantener. Cada

vez que usted necesita para convertir datos de un formato a otro, usted está obligado a aplicar
el código de traducción para realizarlaoperación eincurriren una sobrecarga deprocesamiento.
Componentes, Módulos y Funciones
 Un componente o un objeto no deben confiar en los detalles internos de otros componentes u
objetos. Cada componente u objeto deben llamar a un método de otro objeto o componente, y
ese método deben tener información sobrecómo procesar la solicitud y,en su caso,la forma de
ruta a subcomponentes apropiados u otros componentes. Esto ayuda a crear una aplicación que
es más fácil de mantener y adaptable.
 No sobrecargue la funcionalidad de un componente. Por ejemplo, un componente de
procesamiento de la interfaz de usuario no debe contener código de acceso a datos o intentar
proporcionar funcionalidad adicional. Componentes sobrecargados a menudo tienen muchas
funciones y propiedades queproporcionan funcionalidad denegocio mezclado con funcionalidad
transversales tales como el manejo dela tala y la excepción. El resultado es un diseño quees muy
propenso a errores y difícil de mantener. La aplicación de la responsabilidad individual y la
separación de referente a los principios ayudará a evitar esto.
 Entender cómo los componentes se comuniquen entre sí. Esto requiere una comprensión de los
escenarios deimplementación de la aplicación debeapoyar.Usted debe determinar si todos los
componentes seejecutarán dentro del mismo proceso,o si la comunicación a travésde fronteras
físicas o de proceso debe ser apoyado, tal vez mediante la implementación de las interfaces
basadas en mensajes.
 Mantenga el código transversal abstraído de la lógica de negocio de la aplicación en la medida
de lo posible. Código transversal se refiere al código relacionado con la seguridad, las
comunicaciones,o la gestión operativa como la tala y la instrumentación. Mezcla el código que
implementa estas funciones con la lógica de negocio puede conducir a un diseño que es difícil
extender y mantener. Los cambios en el código transversal requieren tocar todo el código de
lógica denegocio que se mezcla con el código transversal. Considereel uso de marcos y técnicas
(como la programación orientada a aspectos) quepueden ayudar a manejar las preocupaciones
transversales.
 Definir un contrato claro para los componentes. Componentes, módulos y funciones deben
definir una especificación contrato o interfaz que describe su uso y comportamiento
claramente. El contrato debe describir cómo otros componentes pueden acceder a la
funcionalidad interna del componente, módulo o función; y el comportamiento de esa
funcionalidad en términos de condiciones previas, post-condiciones, efectos secundarios,
excepciones, las características de rendimiento y otros factores.
Consideraciones de diseño clave
Esta guía describe las principales decisiones que debe tomar, y que ayudará a asegurar que se tiene en
cuenta todos los factores importantes a medida quecomienza y luego iterativamentedesarrollar el diseño
de su arquitectura. Las decisiones más importantes, que se describen brevemente en las secciones
siguientes, son los siguientes:
Determinar el tipo de aplicación
Elegir el tipo de aplicación adecuadaes la parteclavedel proceso dediseño de una aplicación.Su elección
se rige por sus requerimientos específicos y limitaciones de infraestructura. Muchas aplicaciones tienen
que soportar múltiples tiposdeclientes,y pueden hacer uso demás de uno de los arquetipos básicos. Esta
guía cubre los siguientes tipos de aplicaciones básicas:

 Las aplicaciones diseñadaspara dispositivosmóviles.
 Aplicacionesdecliente enriquecido diseñados para funcionarprincipalmente en un PC cliente.
 AplicacionesdinámicasdeInternet diseñados para ser desplegado a través de Internet, que
apoyan ricos escenariosdela interfazde usuario y de los medios de comunicación.
 Las aplicaciones deservicio diseñadaspara apoyarla comunicación entrelos componentes
débilmente acoplados.
 Aplicaciones Web diseñadas para funcionar principalmente en el servidor en escenarios
totalmente conectados.
Además, proporciona información y directrices para al gunos tipos de aplicaciones más
especializadas. Estos incluyen los siguientes:
 Alojado y aplicaciones y serviciosbasados en la nube.
 OfficeBusiness Applications (OBA) que integran tecnologías de servidor de MicrosoftOfficey
Microsoft.
 SharePointlínea de negocios (LOB) las aplicaciones queproporcionan acceso a la información
de estilo portal denegocios y funciones.
Determinar la estrategia de implementación
Su aplicación puede ser desplegada en una variedad de ambientes, cada uno con su propio conjunto de
restricciones tales como la separación física delos componentes en diferentes servidores ,una limitación
de protocolos de red, configuraciones de cortafuegos y routers, y más. Existen varios modelos de
implementación comunes, que describen los beneficios y consideraciones para una serie de escenarios
distribuidos y no distribuidos. Usted debe equilibrar los requisitos de la aplicación con los patrones
apropiados que el hardware puede soportar, y las limitaciones que el medio ambiente ejerce sobre sus
opciones de implementación. Estos factores influirán en el diseño de su arquitectura.
Determinar las Tecnologías Apropiadas
Al elegir las tecnologías para su aplicación,los factores clavea tener en cuenta son el tipo de aplicación
que se está desarrollando y sus opciones preferidas parala topología deimplementación de aplicaciones
y estilos arquitectónicos.Su elección detecnologías también se regirá por las políticasdela organización,
las limitaciones de infraestructura, capacitación de los recursos, y así sucesivamente. Usted debe
comparar las capacidades de las tecnologías que decide en contra de sus requisitos de aplicación,
teniendo en cuenta todos estos factores antes de tomar decisiones.
Determinar los atributos de calidad
Atributos-tales de calidad como la seguridad,el rendimiento y la facilidad deuso,se pueden utilizar para
enfocar su pensamiento sobre los problemas críticos que su diseño debe resolver. Dependiendo de sus
necesidades,puede que tenga que considerar cadaatributo decalidad cubierto en esta guía, o es posible
que sólo tenga que considerar un subconjunto. Por ejemplo, cada diseño de la aplicación debe tener en
cuenta la seguridad y el rendimiento, pero no cada diseño debe considerar la interoperabilidad o
escalabilidad.Entender sus necesidades y escenarios de implementación primero para que sepa que los
atributos decalidad son importantes para su diseño.Tenga en cuenta que los atributos decalidad pueden
entrar en conflicto;por ejemplo, la seguridad a menudo requiere un compromiso contra el rendimiento
o la facilidad de uso.
Cuando sediseña para dar cabida a los atributos decalidad,tenga en cuenta las siguientes pautas:
 Atributos de calidad son laspropiedades del sistema que están separados de la funcionalidad
del sistema.

 Desde una perspectiva técnica,la implementación de los atributos decalidad puede diferenciar
un buen sistema de uno malo.
 Hay dos tipos de atributos de calidad:los quese miden en tiempo de ejecución,y aquellos que
sólo pueden ser estimadas a través de la inspección.
 Analizar lasventajas y desventajas entrelos atributos de calidad.
Preguntas que debe hacer al considerar losatributosdecalidad son:
 ¿Cuáles son los principales atributosdecalidad requeridospara su aplicación? Identificarlos
como parte del proceso de diseño.
 ¿Cuáles son los requisitos clavepara hacer frente a estos atributos? ¿Son realmente
cuantificable?
 ¿Cuáles son los criterios deaceptación queindicarán queha cumplido con los requisitos?
Determinar las preocupaciones transversales
Preocupaciones transversales representan áreas clave de su diseño que no están relacionados con una
capa específica en la aplicación. Por ejemplo, usted debe considerar la implementación de soluciones
centralizadas o comunes para lo siguiente:
 Un mecanismo de registro que permite que cada capa de registro a un almacén común, o log
para separar las tiendas de tal manera que los resultados se pueden correlacionar después.
 Un mecanismo para la autenticación y la autorización quepasa a través demúltiples identidades
capas para permitir la concesión de acceso a los recursos.
 Un marco de gestión de excepciones que funcionará dentro de cada capa,ya través de las capas
como excepciones se propagan a los límites del sistema.
 Un enfoque de comunicación que se puede utilizar para la comunicación entre las capas.
 Una infraestructura dealmacenamiento en caché común que lepermite almacenar en cachélos
datos en la capa de presentación, la capa de negocio, y la capa de acceso a datos .
La siguientelista describealgunasdelas preocupaciones transversales clavequeusted debe tener en
cuenta cuando la arquitectura de sus aplicaciones:
 Instrumentación y registro. Instrumento todos los eventos críticos para el negocio y críticos del
sistema y registrar los detalles suficientes para recrear los acontecimientos en su sistema sin
incluir información sensible.
 Autenticación. Determinar cómo autenticar a los usuarios y pasar identidades autenticadas a
través de las capas.
 Autorización. Asegurar la debida autorización con granularidad adecuado dentro de cada capa,
ya través de los límites de confianza.
 Gestión de excepciones. Atrapa excepciones en los límites funcionales,lógicos y físicos; y evitar
revelar información confidencial a los usuarios finales.
 Comunicación. Elija protocolos adecuados, reducir al mínimo las llamadas a través de la red, y
proteger los datos sensibles que pasan a través de la red.
 El almacenamiento en caché. Identificar lo que debe ser almacenado en caché, y dónde
almacenar en caché, para mejorar el rendimiento y capacidad de respuesta de la
aplicación.Asegúrese de que tiene en cuenta las cuestiones dela granja deservidores Web y de
aplicaciones en el diseño de almacenamiento en caché.

Capítulo 3
Los patrones arquitectónicos y estilos
Visión general
En este capítulo se describe y analiza los patrones de nivel alto y los principios de uso común
para aplicacionesde hoyendía. Éstosse refierenamenudocomo losestilosarquitectónicos,e
incluyen patrones como cliente / servidor, arquitectura en capas, la arquitectura basada en
componentes,laarquitecturade busde mensajes,ylaarquitecturaorientadaaservicios(SOA).
Para cada estilo, usted encontrará una visión general, los principios clave, los principales
beneficios, y la información que le ayudará a elegir los estilosarquitectónicos adecuadospara
su aplicación. Es importante entender que los estilos describen diferentes aspectos de las
aplicaciones. Por ejemplo, algunos estilos arquitectónicos describen patrones de despliegue,
que algunos describen cuestiones estructura y diseño, y otros describen factores de
comunicación.Porlo tanto,una aplicacióntípica suele utilizarunacombinaciónde másde uno
de los estilos descritos en este capítulo.
¿Qué es un estilo arquitectónico?
Un estiloarquitectónico,avecesllamadounpatrónarquitectónico,esunconjuntodeprincipios-
un patrón de grano grueso que proporciona un marco abstracto para una familia de sistemas.
Un estilo arquitectónico mejora la partición y promueve la reutilización del diseño,
proporcionando soluciones a problemas recurrentes con frecuencia. Usted puede pensar en
estilos de la arquitectura y los patrones como conjuntos de principios que dan forma a una
aplicación. Garlan y Shaw definen un estilo arquitectónico como:
"... Una familia de sistemas en términos de un modelo de organización estructural. Más
específicamente, un estilo arquitectónico determina el vocabulario de los componentes y
conectoresque se puedenutilizarencasosde ese estilo,juntoconunconjuntode restricciones
sobre cómo se pueden combinar. Estos pueden incluir restricciones topológicas en las
descripciones arquitectónicas (por ejemplo, no hay ciclos). Otras limitaciones -por ejemplo,
tener que ver con la ejecución de la semántica podría también ser parte de la definiciónde
estilo”.
La comprensión de los estilos arquitectónicos ofrece varios beneficios. El beneficio más
importante es que proporcionan un lenguaje común. También ofrecen oportunidadespara las
conversaciones que son independiente de la tecnología. Esto facilita un mayor nivel de
conversación que es inclusivo de los patrones y principios,sin entrar en detalles. Por ejemplo,
mediante el uso de estilos de la arquitectura, se puede hablar de cliente / servidor frente a n-
tier. Los estilosarquitectónicosse puedenorganizarporsu área clave de enfoque.Lasiguiente
tablamuestra las principales áreas de interés y los correspondientes estilos arquitectónicos.
Categoría Estilos Arquitectura
comunicación Arquitectura Orientada a Servicios (SOA), Mensaje de autobuses
despliegue Cliente / Servidor, N-Tier, 3-Tier
dominio Dominios impulsados al diseño
estructura Basado en componentes, orientado a objetos, en capas Arquitectura

Resumen de Estilos arquitectónicos clave
La siguiente tabla muestra los estilos arquitectónicos comunes descritos en este capítulo.
Tambiéncontiene unabreve descripciónde cada estilo.Seccionesposterioresde este capítulo
contienen más detalles de cada estilo, así como orientación para ayudarle a elegir los más
adecuados para su aplicación.
Estilos de Arquitectura Descripción
Cliente/Servidor Separa el sistema en dos aplicaciones, donde el cliente hace
peticiones al servidor. En muchos casos, el servidor es una base
de datos con la lógica de la aplicación representada como
procedimientos almacenados.
Basado en Componentes Se descompone el diseño de aplicaciones en componentes
funcionales o lógicos reutilizables queexponen bien definidas las
interfaces de comunicación.
Dominiosimpulsadosal diseño Es un enfoque orientado a objetos para el diseño de
software basado en el dominio de la empresa.
Arquitectura en Capas Agrupaciónde lafuncionalidaddentrode unaaplicaciónen
distintas capas que se apilan verticalmente en la parte
superior de la otra.
Mensaje de Bus Un estilo de arquitectura que determina el uso de un
sistema de software que puede recibir y enviar mensajes a
travésde unoomáscanalesde comunicación,porloque las
aplicaciones puedan interactuar sin necesidad de conocer
los detalles específicos sobre la otra.
N-Tier / 3-Tier Separación de la funcionalidad en segmentos de la misma
manera que el estilo en capas, pero con cada segmento o
nivel situado en un equipo separado físicamente.
Orientado A Objetos Un paradigma de diseño basada en la división de
responsabilidadesparaunaaplicacióno sistemaenobjetos
reutilizablesyautosuficientesindividuales,cadaunoconlos
datos y el comportamiento pertinentes al objeto.
Orientada a Servicios
Arquitectura (SOA)
Se refiere a las aplicaciones que exponen y consumen
funcionalidad como un servicio mediante contratos y
mensajes.
La combinación de estilos arquitectónicos
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. Por ejemplo, es posible que tenga un diseño SOA integrado por servicios
desarrollados utilizando un enfoque de arquitectura en capas y un estilo de arquitectura
orientada a objetos.
Una combinación de estilos de la arquitectura también es útil si usted está construyendo una
aplicación web orientada al público, donde se puede conseguir la separación efectiva de las
preocupaciones por el uso de la arquitectura de estilo en capas. Esto separa la lógica de
presentación de la lógica de negocio y su lógica de acceso a datos. Los requisitos de seguridad
de su organizaciónpodríanforzarloa implementarlaaplicaciónutilizandoel planteamientode
despliegue de 3 niveles, o un despliegue de más de tres pisos.La capa de presentaciónpuede

ser desplegadaala red perimetral,que se encuentraentre laredinternade unaorganizacióny
una red externa. En el nivel de presentación, puede decidir utilizar un patrón separado
presentación (un tipo de estilo de diseño en capas), tales como el Modelo-Vista-Controlador
(MVC),para su modelode interacción. Tambiénpuede optarporunestilode arquitecturaSOA,
y poner en práctica la comunicación basada en mensajes, entre su servidor web y servidor de
aplicaciones.
Si usted está construyendo una aplicación de escritorio, es posible que tenga un cliente que
envíapeticionesaunprograma enel servidor.Eneste caso, esposible implementarel clientey
el servidor utilizando el estilo de la arquitectura cliente / servidor, y utilizar el estilo de la
arquitectura basada en componentes para descomponer el diseño más lejos en componentes
independientesqueexponenalasinterfacesdecomunicaciónapropiados.Utilizandoel enfoque
de diseñoorientadoaobjetosparaestoscomponentesmejorarlareutilización,lacapacidadde
prueba, y la flexibilidad.
Hay muchos factores que influyen en los estilos arquitectónicosque ustedelija. Estos factores
incluyen la capacidad de la organización para el diseño y la ejecució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
El estilo arquitectónico de cliente/servidor describe los sistemas que implican un cliente
independienteysistemade servidor,yunaredde conexióndistribuida.Laformamássimple de
sistema cliente / servidor implica una aplicación de servidor que se accede directamente por
varios clientes, a que se refiere como un estilo arquitectónico de 2 niveles.
Históricamente,laarquitecturacliente/servidor indicaunaaplicaciónde interfazde usuariode
escritoriográficoque comunicaconun servidorde base de datosque contiene granparte de la
lógica de negocio en forma de procedimientos almacenados, o con un servidor de archivos
dedicado. Más en general, 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 utilizando 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 respuestas
utilizando unagamade protocolosyformatosdedatosparacomunicarlainformaciónal cliente.
Hoyendía,algunosejemplosde lacliente /arquitecturade servidorincluyenennavegadorWeb
programas que se ejecutan en Internet o una intranet basan; Operativo Microsoft Windows®
aplicacionesbasadasenelsistemaque accedenalosserviciosde datosenred;aplicacionesque
accedena los almacenesde datosremotos(comolectoresde correoelectrónico,clientesFTPy
herramientas de consulta de base de datos); y herramientas y utilidades que manipulan los
sistemasremotos(comoherramientasde gestióndesistemasyherramientasde monitorización
de red).
Otras variaciones sobre el estilo de cliente / servidor incluyen:
 Sistemas Cliente-Cola-cliente. Este enfoque permite a los clientes comunicarse con
otros clientes a través de una cola basada en servidor. Los clientes pueden leer datos
desde y enviar datos a un servidor que actúa simplemente como una cola para

almacenar los datos. Esto permite a los clientespara distribuir y sincronizar archivos e
información. Esto a veces se conoce como una arquitectura de cola pasiva.
 Peer-to-Peer (P2P). Desarrollado a partir del estilo cliente-Cola-Cliente, el estilo P2P
permite que el clienteyel servidor puedanintercambiarsus rolesconel finde distribuir
y sincronizararchivose informaciónatravésde múltiplesclientes.Se extiende el estilo
de cliente / servidor a través de múltiples respuestas a las solicitudes, los datos
compartidos,labúsquedade recursosycapacidadde resistenciaalaeliminaciónde los
compañeros.
 Los servidores de aplicaciones. Un estilo arquitectónico especializadodonde loshosts
de servidoryejecutaaplicacionesyserviciosqueunclienteligeroaccede atravésde un
navegador o software especializado instalado cliente. Un ejemplo es un cliente de la
ejecuciónde unaaplicaciónque se ejecutaenel servidoratravés de unmarco comoel
de Terminal de Servicios.
Los principales beneficios de la arquitectura cliente / servidor son:
 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 losdatos se almacenansóloenel servidor,
el accesoycambiosalosdatossonmuchomásfácilesde administrarqueenotrosestilos
arquitectónicos.
 Facilidad de mantenimiento.Rolesyresponsabilidades de unsistemade computación
se distribuyenentre variosservidoresque se conocenentre sía travésde unared. Esto
asegura que un cliente permanece inconsciente y no afectado por una reparación de
servidores, actualización o reubicación.
Considere el estiloarquitectónico cliente /servidorsi suaplicaciónse basaservidory apoyaráa
muchos clientes, que está creando aplicaciones basadas en Web expuestos a través un
navegador Web, se están implementando los procesos de negocio que serán utilizados por la
gente en toda la organización, o que están creando servicios para otras aplicaciones para
consumir. El estiloarquitectónicodecliente/servidortambiénesadecuado,al igual quemuchos
enred estilos,cuandodeseacentralizarel almacenamientode datos,copiasde seguridad,ylas
funciones de gestión, o cuando su aplicación debe ser compatible con diferentes tipos de
clientesydiferentesdispositivos.Sinembargo,el cliente /servidorestiloarquitectónico2-Tier
tradicional tiene numerosas desventajas, incluyendo la tendencia de los datos de aplicación y
lógica de negocio para ser estrechamente combinado en el servidor, que puede afectar
negativamente la extensibilidad del sistema y escalabilidad, y su dependencia de un servidor
central, lo que puede afectar negativamente la fiabilidad del sistema. Para abordar estas
cuestiones,el estiloarquitectónicode cliente-servidortienese convirtióenel másgeneral de 3
niveles (o N-Tier) estilo arquitectónico, se describe a continuación, que supera algunas de las
desventajas inherentes en el cliente-servidor 2-Tier arquitectura y proporciona beneficios
adicionales.
Estilo arquitectónico basado en componentes

Arquitecturabasadaencomponentesdescribeunenfoquede ingenieríade software de sistema
diseño y desarrollo. Se centra en la descomposición del diseño en persona componentes
funcionales o lógicos que exponen interfaces de comunicación bien definidos que contiene
métodos, eventos y propiedades. Esto proporciona un mayor nivel de abstracción de los
principios de diseño orientado a objetos, y no se centra en temas como protocolos de
comunicación y estado compartido.
El principio clave del estilo basado en componentes es el uso de componentes que son:
 Reutilizable. Componentes generalmente están diseñados para ser reutilizados en
diferentes escenarios en diferentes aplicaciones.Sin embargo, algunos componentes
pueden estar diseñados para una tarea específica.
 Reemplazable. Los componentes pueden ser sustituidos fácilmente con otros
componentes similares.
 Contextonoespecífico.Loscomponentesestándiseñadosparafuncionarendiferentes
entornosycontextos.Lainformaciónespecífica,comolosdatosestatales,se debepasar
a la componente en lugar de ser incluido en o accesible por el componente.
 Extensible.Uncomponente puedeextenderseapartirde componentesexistentespara
proporcionar nuevo comportamiento.
 Encapsulado. Componentes exponen interfaces que permiten a la persona que llama
para utilizar su funcionalidad, y no revelan detalles de los procesos internos o de
cualquier variable interna o estado.
 Independiente. Los componentes están diseñados para tener dependencias mínimos
sobre otros componentes. Por lo tanto, los componentes se pueden desplegar en
cualquier entorno apropiado sin afectar a otros componentes o sistemas.
Los tiposmáscomunesde loscomponentesutilizadosenaplicacionesincluyencomponentesde
interfaz de usuario, como las redes y los botones (a menudo denominado como controles), y
ayudante y componentes de utilidad que exponen a un subconjunto específicode funciones
utilizadas en otros componentes.Otros tipos comunes de los componentes son los que son
intensivosenrecursos,nose accedeconfrecuencia,ydebe activarse conel enfoquejust-in-time
(JIT) (común en la comunicación remota o escenariosde componentesdistribuidos); y en cola
componentescuyasllamadasmétodopuede serejecutadode formaasíncrona mediante colas
de mensajes y almacenamiento y retransmisión.
Componentesdependendeunmecanismodentrode laplataformaqueproporcionaunentorno
enel que se puedenejecutar,que se refiere alaarquitecturacomocomponente de frecuencia.
Ejemplos de ello son el modelo de objetos componentes (COM) y el modelo de objetos
componentesdistribuido(DCOM) de Windows;y CORBA (CORBA) y Enterprise JavaBeans(EJB)
enotrasplataformas.Arquitecturasdecomponentesagestionarlosmecanismosde localización
de componentesysus interfaces,pasandomensajesocomandos entre los componentes,yen
algunos casos, mantener el estado.
Sin embargo, el componente término se usa a menudo en el sentido más básico de un
constituyenteparte,elementooingrediente.El Microsoft.NETFrameworkproporcionasoporte
para la creación de aplicaciones que utilizan un enfoque basado en componentes tales. Por
ejemplo,estaguíase describe loscomponentesdenegocioydatos,quesoncomúnmenteclases

de código compilado en ensamblados de .NET Framework. Ellos ejecutan bajo el control del
Marco de tiempo de ejecución de .NET, y puede haber más de una de tales componentes en
cada conjunto.
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.
 Coste reducido. El uso de componentes de terceros le permite distribuir el costo de
desarrollo y mantenimiento.
 Facilidadde desarrollo. Los componentesimplementaninterfacesbienconocidaspara
proporcionar funcionalidad definida, lo que permite el desarrollo sin afectar a otras
partes del sistema.
 Reutilizable. El uso de componentes reutilizables significa que pueden ser utilizados
para difundirel desarrolloyel coste de mantenimientoatravésde variasaplicacioneso
sistemas.
 Mitigaciónde complejidadtécnica.Componentesmitigarlacomplejidadatravésel uso
de un recipiente de componente y sus servicios. Servicios de componente Ejemplo
incluirlaactivaciónde componentes,lagestiónde todalavida,el métodode puestaen
cola, concurso completo, y transacciones.
Lospatronesde diseño,comoelpatrónde inyecciónde dependenciaoel patrónServiceLocator
se pueden utilizar para gestionar las dependencias entre los componentes, y promover la
articulación flexible y reutilización. Estos patrones se utilizan a menudo para construir
aplicaciones compuestas que combinan y reutilizar los componentes a través de múltiples
aplicaciones.
Estilo Arquitectónico Dominio Impulsado al Diseño (Domain Driven Design)
Domain Driven Design (DDD) es un enfoque orientado a objetos para el diseño de software
basado en el dominiode la empresa,suselementosycomportamientos,ylas relacionesentre
ellos.Suobjetivoespermitirque lossistemasde software que sonuna realizacióndel dominio
del negocio subyacente mediante la definición de un modelo de dominio se expresa en el
lenguaje delosexpertosenlossectoresde negocios.El modelodedominiopuede servistocomo
un marco a partir del cual las soluciones pueden entonces ser racionalizado.
Para aplicar Domain Driven Design, usted debe tener un buen conocimiento del dominio del
negocioque deseamodelar,oserexpertoenlaadquisiciónde tal conocimientodel negocio. El
equipode desarrolloamenudo trabajacon expertosenel dominiode negocioparamodelarel
dominio. Los arquitectos, desarrolladores y expertos en la materia tienen diversos orígenes,y
en muchos ambientes utilizarán diferentes lenguajes para describir sus objetivos, diseños y
requerimientos. Sin embargo, dentro Domain DrivenDesign, todo el equipo se compromete a
utilizar un solo idioma que se centra en el dominio del negocio, y que excluye cualquier jerga
técnica.
A medidaque el núcleodelsoftwareesel modelode dominio,queesunaproyeccióndirectade
este lenguaje común,que permite que el equipoparaencontrarrápidamente laslagunasenel
software mediante el análisisde lalenguaa su alrededor. La creaciónde una lenguacomún no
esmás que un ejerciciode aceptaciónde lainformaciónde losexpertosde dominioyaplicarlo.

Muy a menudo, los problemas de comunicación dentro de los equipos de desarrollose deben
no sólo a la mala interpretacióndel lenguaje del dominio,sinotambiénporel hechode que el
lenguaje del dominioesensímismoambiguo.El procesoDrivenDesigndominiotieneel objetivo
nosólode laaplicaciónde lalenguaquese utiliza,sinotambiénmejoraryperfeccionarel idioma
del dominio. Estoasuvezbeneficiael softwarese construye,yaqueelmodeloesunaproyección
directa de la lengua dominio.
Conel finde ayudaramantenerel modelocomounaconstruccióndel lenguajepuroyútil,debe
implementar típicamente una gran cantidad de aislamiento y encapsulado dentro del modelo
de dominio. En consecuencia, un sistema basado en dominio Driven Design puede venir a un
costorelativamente alto.MientrasDomainDrivenDesignofrece muchasventajastécnicas,tales
como el mantenimiento, se debe aplicar sólo a los dominios complejos donde el modelo y los
procesos lingüísticos proporcionan claros beneficios en la comunicación de información
compleja, y en la formulación de un entendimiento común del dominio.
Los siguientes son los principales beneficios del estilo Domain Driven Design:
 Comunicación. Todas las partes dentro de un equipo de desarrollo pueden utilizar el
modelode dominioylasentidadesquedefine acomunicarconocimientosynecesidades
de negociosutilizandounlenguajede dominio denegociocomún,sinnecesidadde jerga
técnica.
 Extensible. El modelo de dominio a menudo es modular y flexible, lo que es fácil
actualizar y ampliar las condiciones y requisitos cambian.
 Comprobable. Los objetos del modelo de dominio están débilmente acoplados y
cohesionada, lo que 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, 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énpuedeserunmétodoideal si ustedtienelaempresagrandeycomplejaescenarios
de datos que son difíciles de administrar mediante otras técnicas.
Para un resumen de dominio impulsado técnicas de diseño, consulte "Driven Design dominio
Rápidamente "en http://www.infoq.com/minibooks/domain-driven-design-quickly.
Como alternativa, consulte "Domain-Driven Design: afrontar la complejidad en el Corazón de Software"
por Eric Evans (Addison-Wesley,ISBN: 0-321-12521-5) y "Aplicación deDriven-Domain Diseño y Patrones
"de Jimmy Nilsson (Addison-Wesley, ISBN: 0-321-26820-2).
Estilo arquitectónico en capas
Arquitectura en capas se centra en la agrupación de funcionalidad relacionada dentro de una
aplicación en distintas capas que se apilan verticalmente en la parte superior de la otra.
Funcionalidad dentro de cada capa está relacionado por un papel común o responsabilidad.
La comunicación entre capas es explícita y débilmente acoplado. Estratificación su aplicación
adecuada ayuda a mantener una fuerte separación de intereses que, a su vez, apoya la
flexibilidad y facilidad de mantenimiento.
El estiloarquitectónicocapashasidodescritocomounapirámideinvertidade lareutilizaciónen
laque cada capa de agregadosde lasresponsabilidadesyabstraccionesde lacapadirectamente
debajo de ella. Con estricta capas, componentes en una capa pueden interactuar sólo con

componentesenlamismacapaoconcomponentesde lacapadirectamentedebajode él.Capas
más relajadapermite que loscomponentesenuna capa para interactuarcon componentesen
la misma capa o con componentes en cualquier capa inferior.
Las capas de una aplicaciónpuedenresidirenel mismoequipofísico(el mismonivel) opueden
estar distribuidos en equipos independientes (n-tier), y los componentes de cada capa
comunicarse concomponentesde otrascapasatravésde interfacesbiendefinidas.Porejemplo,
un típico diseño de aplicaciones web consiste en una capa de presentación (funcionalidad
relacionada con la interfaz de usuario), una capa de negocio (procesamiento de reglas de
negocio), y una capa de datos (funcionalidad relacionada con el acceso a datos, a menudo
aplicadocasi ensu totalidada partir de datos de altonivel marcosde acceso).Para losdetalles
de la aplicación estilo arquitectónico de n niveles, ver N-Tier / 3-Tier estilo arquitectónico más
adelante en este capítulo.
Principios comunes para los diseños que utilizan el estilo arquitectónico en capas incluyen:
 Abstracción. Arquitecturaencapas abstrae lavistadel sistema ensuconjunto mientras
que proporciona suficiente detalle para comprender las funcionesy responsabilidades
de las capas individuales y la relación entre ellos.
 La encapsulación.Nohaysuposicionesdebenhacerse sobre lostiposdedatos,métodos
y propiedades, o la aplicación durante el diseño, ya que estas funciones no están
expuestos a los límites de capas.
 Claramente definido capas funcionales. La separación entre la funcionalidad en cada
capa esclara.Las capas superiores,comoel envíode lacapade presentacióncomandos
para bajar capas, como las capas de negocio y de datos, y pueden reaccionar a los
acontecimientos en estas capas, permitiendo que los datos fluyen tanto hacia arriba
como hacia abajo entre las capas.
 Alta cohesión.Biendefinidosloslímitesde responsabilidadparacadacapa,ylagarantía
de que cada capa contiene funcionalidad directamente relacionados con las tareas de
esa capa, le ayudará a maximizar la cohesión dentro de la capa.
 Reutilizable. Capas inferiores no tienen dependencias en las capas más altas,
potencialmente 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.
Ejemplos de aplicaciones en capas incluyen la línea de negocio de las aplicaciones como los
sistemasde contabilidadyde gestiónde clientes(LOB);aplicacionesempresarialesbasadasen
la Web y sitios Web y de escritorio de la empresa o clientes inteligentes con servidores de
aplicaciones centralizadas para la lógica de negocio.
Una serie de patronesde diseñosoportalaarquitecturaencapas.Por ejemplo,lospatronesde
presentaciónseparadosabarcanuna gama de patronesque el manejode las interaccionesdel
usuario de la interfaz de usuario, la lógica de presentación y de negocios, y los datos de la
aplicación con la que trabaja el usuario. Presentación Separado permite a los diseñadores
gráficos para crear una interfaz de usuario mientras que los desarrolladores generar el código
para conducirlo. La división de la funcionalidad en papeles separados de esta manera
proporciona mayores oportunidades para poner a prueba el comportamiento de los roles
individuales. Los siguientes son los principios fundamentales de los Patrones de presentación
separados:

 Separación de preocupaciones. Patrones de presentación separados dividen
preocupaciones de procesamiento de interfaz de usuario en funciones distintas; por
ejemplo, MVC tiene tres funciones: el modelo, la vista y el controlador. El modelo
representa los datos (tal vez un modelo de dominioque incluya reglas de negocio); la
vistarepresentalainterfazde usuario;yel controladormanejalassolicitudes,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 cuando los datos manejados por los cambios de
modelos.
 Manejo de eventos delegada. El controlador maneja eventos disparados desde los
controles de interfaz de usuario en la vista.
Otros ejemplos de patrones de presentación son separados por el patrón Ver pasiva y el
Supervisor Presentador (o Supervisor Controlador) patrón. Los principales 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. Puede
aumentar o disminuir el nivel de abstracción que utiliza en cada capa de la pila
jerárquica.
 Aislamiento. Permite aislar mejoras tecnológicas a capas individuales con el fin para
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, y organiza el código en secciones más manejables.
 Rendimiento. La distribución de las capas a través de múltiples niveles físicos puede
mejorar la escalabilidad, tolerancia a fallos y rendimiento.
 Reutilización. Roles promuevenla reutilización. Por ejemplo, en MVC, el controlador
puede amenudoserreutilizadosconotroscompatiblesVistasafinde proporcionaruna
función específica o una vista personalizado por el usuario a los mismos datos y
funcionalidad.
 Testabilidad. El aumento de la capacidad de prueba surge de tener interfacesde capa
biendefinidos,asícomolacapacidadde cambiarentre diferentesimplementacionesde
la capa interfaces. Patrones de presentación separados le permiten construir objetos
simulados que imitan el comportamiento de los objetos concretos tales como el
Modelo, Controlador, o Vista durante la prueba.
Considere el estiloarquitectónicoencapassi tiene capasexistentesque sonadecuadosparasu
reutilizaciónenotrasaplicaciones,yatieneaplicacionesque exponenalosprocesosde negocio
adecuadosatravésde interfacesde servicio,osuaplicaciónescomplejayel diseñode altonivel
de las demandas de separación para que los equipospueden centrarse en diferentes áreas de
funcionalidad. El estiloarquitectónicoencapas tambiénes apropiadosi su aplicacióndebe ser
compatible con diferentes tipos de clientes y diferentes dispositivos, o si desea implementar
reglas y procesos de negocio complejos y / o configurables.
Considere laposibilidadde unpatrónPresentaciónSeparadosi quieresmejorarlacapacidadde
prueba y mantenimiento simplificado de la funcionalidad de la interfaz de usuario, o si desea
separarla tarea de diseñarlainterfazde usuariodesde el desarrollodel códigode lalógicaque
loimpulsa.EstospatronestambiénsonapropiadoscuandosuvistaUInocontieneningúncódigo
de procesamiento de solicitudes, y no implementa ninguna lógica empresarial.
Mensaje autobús Estilo Arquitectónico

Arquitecturade busde mensajesdescribeelprincipiode lautilización deunsistemade software
que puede recibiryenviarmensajesatravésde unoomás canalesde comunicación, porloque
las aplicaciones puedan interactuar sin necesidad de conocer los detalles específicos sobre la
otra. Es un estilopara el diseñode aplicacionesenlasque la interacciónentre lasaplicaciones
se logra mediante el paso de mensajes (por lo general de forma asíncrona) en un bus común.
Las implementacionesmáscomunesde bus de mensajesarquitecturauso,ya sea un routerde
mensajes o una publicación / suscripción patrón, y se implementan a menudo utilizando un
sistema de mensajería como Message Queue Server. Muchas implementaciones consisten en
aplicacionesindividualesque se comunicanmedianteesquemascomunesyunainfraestructura
compartida para enviar y recibir mensajes. Un bus de mensajes proporciona la capacidad de
manejar:
 Comunicacionesde mensajesorientada.Todalacomunicaciónentrelasaplicacionesse
basa en mensajes que utilizan esquemas conocidos.
 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
lascualessoportatareas específicas,comoparte de un itinerario de etapas múltiples.
 Las modificacionesalalógica de procesamiento.Debidoalainteracciónconel autobús
se basa en esquemas y comandos comunes,puede insertar o eliminar aplicaciones en
el autobús para cambiar la lógica que se utiliza para procesar los mensajes.
 Integracióncon diferentesambientes.Mediante el usode unmodelode comunicación
basada en mensajes basados en normas comunes, se puede interactuar con las
aplicaciones desarrolladas para diferentes entornos, como Microsoft .NET y Java.
Diseños bus de mensajes se han utilizado para apoyar las reglas de procesamiento complejas
durante muchosaños. El diseñoproporcionaunaarquitecturaconectable que permite insertar
aplicaciones en el proceso, o mejorar la escalabilidaduniendo varias instancias de la misma
aplicación en el autobús. Las variaciones en el estilo bus de mensajes incluyen:
 Enterprise Service Bus (ESB). Sobre la base de los diseños de bus de mensajes,un ESB
utilizalosserviciosparala comunicaciónentre el bus y loscomponentesconectadosal
bus. Un ESB suele proporcionarservicios que transformanlosmensajesde unformato
a otro, permitiendo a los clientes que utilizan formatos de mensaje incompatiblesse
comuniquen entre sí.
 InternetService Bus (ISB). Esto essimilaraun bus de serviciosempresariales,perocon
aplicaciones alojadasenlanube enlugarde enunaredempresarial.Unconceptobásico
de ISBesel usode identificadoresuniformesde recursos(URI) ypolíticasparacontrolar
el enrutamiento de la lógica a través de aplicaciones y servicios en la nube.
Los principales 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. Complejidad de aplicación se reduce debido a que cada aplicación
sólo necesita saber cómo comunicarse con el autobús.
 Flexibilidad. El conjunto de aplicaciones que componen un proceso complejo, o los
patronesde comunicaciónentre lasaplicaciones,se puede cambiarfácilmenteparaque
coincidacon loscambiosen losrequisitosde negocioousuarios,simplemente através
de cambios en la configuración o los parámetros que controlan el enrutamiento.

 Acoplamiento débil. Mientras aplicaciones exponena una interfaz adecuada para la
comunicaciónconel busde mensajes,nohaydependenciade laaplicaciónensí,loque
permite cambios, 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. Aunque unaaplicaciónbus mensaje añade complejidadala
infraestructura, cadaaplicacióndebe sercompatible conunaúnicaconexiónconel 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úan entre sí para realizar tareas, o si desea combinar varias tareas en una sola
operación. Este estilo también es apropiado si está implementandouna tarea que requiere la
interacción con aplicaciones externas, o las aplicaciones alojadas en diferentes ambientes.
N-Tier / 3-Tier Estilo Arquitectónico
N-tier y 3-nivel están estilos arquitectónicos de despliegue que describen la separación de la
funcionalidadensegmentosdelamismamaneraque elestiloencapas,peroconcadasegmento
siendo un nivel que puede ser situado en un equipo separado físicamente. Evolucionaron a
travésdel enfoque orientadoacomponentes,generalmente utilizandométodosespecíficosde
la plataforma para la comunicación en lugar de un enfoque basado en el mensaje.
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, excepto para aquellos
inmediatamente por encima y por debajo de ella. El nivel enésimosólo tiene que saber cómo
manejarunapeticiónde lan + tierdía 1, la formaenque transmitaesasolicitudenel nivelde n
día 1 (si lo hay),ycómo manejarlosresultadosde lasolicitud. Lacomunicaciónentre niveleses
típicamente asíncrona con el fin de apoyar una mejor escalabilidad.
Arquitecturas de N-Capas suelen tener por lo menos tres partes lógicas separadas, cada uno
situado en un servidor físico independiente. Cada parte es responsable de la funcionalidad
específica.Cuandose utilizaunenfoque de diseñoencapas,unacapase implementaenunnivel
si más de un servicio o aplicación depende de la funcionalidad expuesta por la capa.
Un ejemplode laarquitecturade N-capas/3-tieresunaaplicaciónwebfinancieratípica,donde
la seguridad es importante. La capa de negocio se debe implementar un cortafuegos, lo que
obliga al despliegue de la capa de presentación en un nivel aparte en la red perimetral. Otro
ejemplo es una aplicación conectada rico cliente típico, donde la capa de presentación se
implementaenlosequiposcliente ylacapa capa de negocioyacceso a losdatos se despliegan
en uno o más niveles de servidor.
Los principales beneficios de la N-tier / 3-tier estilo arquitectónico son:
 Mantenibilidad. Debido a que cada nivel es independiente de los otros niveles,
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 escala de forma
independiente, se aumenta la flexibilidad.
 Disponibilidad. Las aplicaciones pueden aprovechar la arquitectura modular de
sistemasque permitanel usode componentesfácilmenteescalables,loqueaumentala
disponibilidad.
Considere bienlaN-tieroel estiloarquitectónicode 3niveles,si losrequisitosde procesamiento
de las capas en la aplicación difieren de tal manera que el procesamiento en una capa podría
absorberrecursossuficientesparafrenarel procesamientoenotrascapas,o si losrequisitosde
seguridad de las capas en la aplicación diferir. Por ejemplo, la capa de presentación no debe
almacenarlos datos sensibles,si bienestopuede seralmacenadaenlas capas de negocioy de
datos. La N-tiero el estiloarquitectónicode 3 nivelestambiénesapropiadosi ustedquiereser
capaz de compartir lalógicade negocioentre aplicaciones,yustedtieneel hardware suficiente
para asignar el número necesario de servidores para cada nivel.
Considere el usode sólotres nivelessi estádesarrollandounaaplicaciónde intranet,donde se
encuentrantodoslosservidoresdentrode laredprivada;ounaaplicaciónde Internetdonde los
requisitosde seguridadnolimitanel despliegue de lalógicade negocioenel frente delservidor
Web o aplicación pública. Considere el uso de más de tres pisos si los requisitos de seguridad
dictan que la lógica de negocio no se puede implementar en la red perimetral, o la aplicación
hace un uso intensivo de los recursos y desea descargar esa funcionalidad a otro servidor.
Estilo Arquitectónico Orientado a Objetos
Arquitectura orientada a objetos es un paradigma de diseño basado en la división de
responsabilidades para una aplicación o sistema en objetos reutilizables y autosuficientes
individuales, cada uno con los datos y el comportamiento pertinentes al objeto. Un diseño
orientadoaobjetosconsideraqueunsistemacomounaseriede objetosquecooperan,enlugar
de un conjunto de rutinas o instrucciones de procedimiento. Los objetos son discretos,
independientee imprecisa; se comunicanatravésde interfaces,llamandoamétodosoacceder
a las propiedadesde otrosobjetos,ymediante el envíoyrecepciónde mensajes.Losprincipios
fundamentales de la arquitectura orientada a objetos son:
 Abstracción. Esto le permite reducirunaoperacióncomplejaenunageneralizaciónque
conservalas características básicasde la operación. Porejemplo,unainterfazabstracta
puede ser una conocida definición que soporta las operaciones de acceso a datos
utilizando métodos simples como obtener y actualizar. Otra forma de abstracción se
podría metadatos utiliza para proporcionar una asignación entre los dos formatos que
contienen datos estructurados.
 Composición.Los objetospuedenserensambladasapartir de otrosobjetos,y pueden
optar por ocultar estos objetos internos de otras clases ni las exponga las interfaces
simples.
 Herencia. Los objetospuedenheredarde otrosobjetos,yel uso de la funcionalidaden
el objeto de base o anularlo para implementar un nuevo comportamiento. Por otra
parte,laherenciahace que el mantenimientoylasactualizacionesmásfáciles,como los
cambios en el objeto base se propagan automáticamente a los objetos que heredan.
 La encapsulación. Objetos exponen funcionalidad sólo a través de los métodos,
propiedades y eventos, y ocultan los detalles internos tales como el estado y las
variablesde otrosobjetos.Estohace que sea más fácil para actualizaro reemplazarlos

objetos,siempre ycuandosus interfacessoncompatibles,sinafectara otros objetosy
código.
 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.Los objetospueden serdisociadosde losconsumidoresmediante
ladefinicióndeunainterfazabstractaqueimplementaelobjetoyelconsumidorpuedan
entender.Estole permite proporcionarimplementacionesalternativassinafectaralos
consumidores de la interfaz.
Los usos más comunes del estilo orientado a objetos incluyen la definición de un modelo de
objetos que apoya las operaciones científicas o financieros complejos, y la definición de los
objetos que representan los artefactos del mundo real dentrode un dominio empresarial (por
ejemplo, un cliente o una orden). Este último es un proceso implementado comúnmente
utilizando el dominio impulsado estilo de diseño más especializada, que se aprovecha de los
principios del estilo orientado a objetos. Para obtener más información, consulte " Domain
Driven Design Estilo arquitectónico "anteriormente en este capítulo.
Los principales beneficios de la arquitectura orientada a objetos son que es:
 Comprensible.Al trazar la aplicaciónmásde cerca a los objetosdel mundoreal,loque
hace más comprensible.
 Reutilizable. Se prevé la reutilización a través de polimorfismo y abstracción.
 Comprobable. Prevé una mejor capacidad de prueba a través de la encapsulación.
 Extensible.Laencapsulación,polimorfismoyabstracciónaseguranque un cambioenla
representaciónde datosnoafectaalasinterfacesque el objetoexpone,loque limitaría
la capacidad de comunicarse e interactuar con otros objetos.
 Altamente cohesivo. Al ubicarlos métodosycaracterísticassoloacerca de un objeto,y
el usode diferentesobjetosparadiferentesconjuntosdecaracterísticas,sepuedelograr
un alto nivel de cohesión.
Considere el estiloarquitectónicoorientadoaobjetos,si ustedquiere modelarsuaplicaciónen
funciónde losobjetosdelmundoreal ylasacciones,osi yatiene objetosyclasesque coinciden
con el diseñoyel funcionamientoadecuados.El estiloorientadoaobjetostambiénesadecuado
si debe encapsular la lógica y los datos juntos en componentes reutilizables o si tiene lógica
empresarial compleja que requiere la abstracción y comportamiento dinámico.
Estilos Arquitectónicos Orientados a Servicios
Arquitectura orientada a servicios (SOA) permite la funcionalidad de la aplicación que se
proporcionacomo un conjuntode servicios,yla creación de aplicacionesque hacenuso de los
servicios de software. Los servicios están débilmente acoplados, ya que utilizan las interfaces
basadasen estándaresque puedenserinvocados,publicados,ydescubrieron. ServiciosenSOA
se centranenproporcionarun esquemaylainteracciónbasadaenmensajesconunaaplicación
a travésde interfaces quesonámbitodelaaplicación,ynode componente uobjeto-basado.Un
servicio SOA no debe ser tratado como un proveedor de servicio basado en componentes.
El estilo SOA puede empaquetar los procesos de negocio en los servicios interoperables,
utilizando una variedad de protocolos y formatos de datos para comunicar información. Los
clientes y otros servicios pueden acceder a los servicios locales que se ejecutan en el 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
versionado de forma independiente.
 Los servicios son distribuibles. Los servicios puedenestar ubicados en cualquier parte
de una red, de forma local o remota, siempre y cuando la red es compatible con los
protocolos de comunicación necesarios.
 Losserviciosestándébilmenteacoplados. Cadaservicioesindependiente delosdemás,
y se puede reemplazar o actualizar sin romper las aplicaciones que lo utilizan como
siempre que la interfaz sigue siendo compatible.
 Servicios participación de esquema y de contrato, no de clase. Servicios contratos
sobre acciones y esquemas cuando se comunican, las clases no internos
 La compatibilidad se basa en la política. La política en este caso significa la definición
de características tales como el transporte, el protocolo y la seguridad.
Los ejemplos comunes de aplicaciones orientadas a servicios incluyen el intercambio de
información,lamanipulaciónprocesosde variospasos,como lossistemasde reservay tiendas
enlínea,laexposiciónde datososerviciosespecíficosde laindustriaatravésde unaextranet,y
la creación de mashups que combinan información de múltiples fuentes.
Los principales beneficios de la arquitectura SOA son:
 Alineaciónde dominio. Lareutilizacióndelosservicioscomunesconinterfacesestándar
aumenta las oportunidades de negocio y de tecnología y reduce los costos.
 Abstracción. Serviciossonautónomosy se accede a travésde un contrato formal,que
proporciona el acoplamiento débil y la abstracción.
 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. Los servicios pueden ser granular con el fin de proporcionar una
funcionalidad específica, en lugar de duplicar la funcionalidad en el número de
aplicaciones, que elimina la duplicación.
Considerar el estilo SOA si usted tiene acceso a los servicios adecuados que desea volver a
utilizar; puede adquirir servicios adecuados proporcionados por una empresa de
alojamiento;quierenconstruiraplicacionesquecomponenunavariedaddeservicios enunasola
interfazde usuario; o que está creando Software másServicios(S+ S), Software como Servicio
(SaaS),o aplicacionesbasadasen la nube. El estiloSOA es adecuadocuando se debe apoyar la
comunicaciónbasadaenmensajes entre lossegmentosde lasolicitudyexponerlafuncionalidad
de una manera independiente de la plataforma, cuando se quiere aprovechar los servicios
federadoscomolaautenticación,osi deseaexponerserviciosque se puedendescubriratravés
de directoriosypuedenserutilizadosporlosclientesque notienenconocimientopreviode los
interfaces.

¿Qué es la arquitectura de software?

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to ¿Qué es la arquitectura de software?

Similar to ¿Qué es la arquitectura de software? (20)

More from Israel Rey

More from Israel Rey (20)

Recently uploaded

Recently uploaded (20)

¿Qué es la arquitectura de software?