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 estructurada que cumple con todos los requisitos técnicos y operativos, al tiempo que optimiza la calidad común atributos tales como el rendimiento, la seguridad y capacidad de administración. Se trata de una serie de decisiones basadas en una amplia gama de factores, y cada una de estas decisiones pueden tener un impacto considerable en la calidad, rendimiento, facilidad de mantenimiento, y en general el éxito de la aplicación.

Philippe Kruchten, Grady Booch, Kurt Bittner, y Rich Reitman derivan y refinado una definición de la arquitectura basada en el trabajo de Mary Shaw y David Garlan (Shaw y Garlan 1996). Su definición es:

"Arquitectura de software abarca el conjunto de decisiones importantes sobre la organización de un sistema de software que incluye la selección de la estructural elementos y sus interfaces por el cual el sistema está compuesto; comportamiento como especificado en la colaboración entre dichos elementos; composición de éstos estructural y elementos de comportamiento en subsistemas más grandes; y un estilo arquitectónico que guía esta organización. Arquitectura de 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 temas recurrentes comunes a la hora de explicar la arquitectura. Él identifica estos temas como:

"El desglose de más alto nivel de un sistema en sus partes; las decisiones que sean difícil de cambiar; hay múltiples arquitecturas en un sistema; lo que es arquitectónicamente significativo puede cambiar durante la vida de un sistema; y, al final, la arquitectura se 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 propiedades de esos elementos, y las relaciones entre ellos. La arquitectura es de que se trate con el lado público de interfaces; detalles privados de los elementos Detalles que tiene que ver exclusivamente con la aplicación interna no-son arquitectónica".

¿Por qué es importante arquitectura?

Al igual que cualquier otra estructura compleja, el software debe ser construido sobre una base sólida. No considerar escenarios clave, en su defecto a diseñar para los problemas comunes, o en su defecto para apreciar las consecuencias a largo plazo de las decisiones clave puede poner su aplicación en riesgo. Herramientas y plataformas modernas ayudan a simplificar la tarea de creación de aplicaciones, pero no reemplazan la necesidad de diseñar la aplicación con cuidado, basado en sus escenarios y requerimientos específicos. Los riesgos expuestos por la mala arquitectura incluyen software que es inestable, no es capaz de soportar

los requerimientos de 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.

Compensaciones son probables, y un saldo a menudo debe encontrarse entre los requisitos de la competencia a través de estas tres áreas. Por ejemplo, la experiencia general del usuario de la solución es muy a menudo una función del negocio y la infraestructura de TI, y los cambios en 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 invertir en el hardware necesario para cumplir con ese objetivo 100 por ciento del tiempo. Un punto de equilibrio podría ser la de alcanzar la meta sólo el 80 por ciento del 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 en la naturaleza. En otros casos, las decisiones son más sobre el diseño, y cómo ayudan a 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

Arquitectura de la aplicación busca construir un puente entre los requerimientos del negocio y los requisitos técnicos mediante la comprensión de los casos de uso y, a continuació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ño es suficientemente flexible para ser capaz de manejar la deriva natural que se producirá con el tiempo en hardware y tecnología de software, así como en escenarios y necesidades de los usuarios. Un arquitecto debe tener en cuenta el efecto general de las decisiones de 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 entender las fuerzas clave que están dando forma a las decisiones arquitectó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 demanda de las empresas para resultados más rápidos, mejor soporte para variar los estilos de 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 usuario definir la forma en que interactúan con su aplicación en lugar de dictar a ellos, pero no sobrecargarlos con opciones innecesarias y ajustes que pueden dar lugar a confusión. Comprender los escenarios clave y que sean lo más simple posible; hazlo fácil de encontrar información y utilizar la aplicación.

La madurez del mercado. Tome ventaja de la madurez del mercado, aprovechando las opciones de plataforma y tecnología existentes. Basarse en los entornos de aplicaciones de alto nivel donde tiene sentido, de modo que usted pueda centrarse en

lo que es un valor único en su aplicación en vez de crear algo que ya existe y se puede volver a utilizar. Los patrones de uso que proporcionan una rica fuente de soluciones probadas para los 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én puede tomar ventaja de las técnicas de orientación de servicio tales como SOA para proporcionar interoperabilidad con otros sistemas.

Las tendencias futuras. Cuando la construcción de su arquitectura, comprende las tendencias del futuro que podrían afectar su diseño después de la implementación. Por ejemplo, considere las tendencias de la rica interfaz de usuario y los medios de comunicación, modelos de composición tales como mashups, aumentando el ancho de banda de la red y disponibilidad, uso creciente de dispositivos móviles, la mejora continua en el rendimiento del hardware, el interés en los modelos de la comunidad y la edición personal, el aumento de la computación basada en la nube y operación remota.

Los Principios de Arquitectura

El pensamiento actual sobre la arquitectura supone que su diseño va a evolucionar con el 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áles son las partes funcionales de la arquitectura que representan el mayor riesgo si consigues que están equivocados?

¿Cuáles son las partes de la arquitectura que tienen má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. En su lugar, mantener sus opciones abiertas para el cambio futuro. Habrá aspectos de su diseño que usted debe fijar al inicio del proceso, que pueden representar se requiere un costo significativo de rediseño. Identificar estas áreas rápidamente e invertir el tiempo necesario para 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 analizar su impacto. Sin embargo, no formular el modelo en la medida en que 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 decisiones que 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 todas las partes interesadas, y para permitir una rápida comunicación de los cambios en 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ás a menudo. Invertir en conseguir que estas decisiones clave bien la primera vez para que el diseño es más flexible y menos probable que se rompa por los cambios.

Considere el uso de un enfoque incremental e iterativo para refinar su arquitectura. Comience con una arquitectura de referencia para obtener la imagen derecha grande, y luego evolucionar arquitecturas candidatas como prueba iterativo y mejorar su arquitectura. No trate de hacerlo todo bien desde el principio-diseño tiempo tanto como sea posible con el fin de empezar a probar el diseño frente a los requisitos y supuestos. Añadir Iterativamente detalles al diseño a través de múltiples pases para asegurarse de que usted obtenga las grandes decisiones derechas 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é manera es esta arquitectura una mejora con respecto a la línea de 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 arquitectura de software. Arquitectura de software se describe a menudo como la organizació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 de los 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 de este 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 claveEn 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 de los 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ífica o 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, especialmente para 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 interfaz de 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 centrarse en esa área específica y no se deben mezclar código de otras áreas de interé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 que realice para una aplicación. En algunos casos, puede ser necesario simplificar la estructura 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 desde un punto de vista de los negocios también. Las siguientes pautas de alto 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 tablas o vistas en una base de datos, 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 de clases 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 de có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 de control de calidad automatizados durante el 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 despliegue global y funcionamiento. Utilice las herramientas de control de calidad 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 de este enfoque es que una característica o funcionalidad pueden optimizarse independientemente 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 de entender y de diseño, y facilita la gestión de los 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 de entender 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 mediante la definición de componentes de la interfaz tales como una fachada con 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 de implementar, 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 realizar la operación e incurrir en una sobrecarga de procesamiento.

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 sobre có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 que proporcionan funcionalidad de negocio mezclado con funcionalidad transversales tales como el manejo de la tala y la excepción. El resultado es un diseño que es 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 de implementación de la aplicación debe apoyar. Usted debe determinar si todos los componentes se ejecutarán dentro del mismo proceso, o si la comunicación a través de 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 de negocio que se mezcla con el código transversal. Considere el uso de marcos y técnicas (como la programación orientada a aspectos) que pueden 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 claveEsta 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 que comienza y luego iterativamente desarrollar 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ónElegir el tipo de aplicación adecuada es la parte clave del proceso de diseñ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 tipos de clientes, y pueden hacer uso de más de uno de los arquetipos básicos. Esta guía cubre los siguientes tipos de aplicaciones básicas:

Las aplicaciones diseñadas para dispositivos móviles. Aplicaciones de cliente enriquecido diseñados para funcionar principalmente en un PC cliente. Aplicaciones dinámicas de Internet diseñados para ser desplegado a través de Internet, que

apoyan ricos escenarios de la interfaz de usuario y de los medios de comunicación. Las aplicaciones de servicio diseñadas para apoyar la comunicación entre los 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 algunos tipos de aplicaciones más especializadas. Estos incluyen los siguientes:

Alojado y aplicaciones y servicios basados en la nube. Office Business Applications (OBA) que integran tecnologías de servidor de Microsoft Office y

Microsoft. SharePoint línea de negocios (LOB) las aplicaciones que proporcionan acceso a la información

de estilo portal de negocios y funciones.

Determinar la estrategia de implementaciónSu 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 de los 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 ApropiadasAl elegir las tecnologías para su aplicación, los factores clave a tener en cuenta son el tipo de aplicación que se está desarrollando y sus opciones preferidas para la topología de implementación de aplicaciones y estilos arquitectónicos. Su elección de tecnologías también se regirá por las políticas de la 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 calidadAtributos-tales de calidad como la seguridad, el rendimiento y la facilidad de uso, 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 cada atributo de calidad 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 de calidad son importantes para su diseño. Tenga en cuenta que los atributos de calidad pueden entrar en conflicto; por ejemplo, la seguridad a menudo requiere un compromiso contra el rendimiento o la facilidad de uso.Cuando se diseña para dar cabida a los atributos de calidad, tenga en cuenta las siguientes pautas:

Atributos de calidad son las propiedades del sistema que están separados de la funcionalidad del sistema.

Desde una perspectiva técnica, la implementación de los atributos de calidad puede diferenciar un buen sistema de uno malo.

Hay dos tipos de atributos de calidad: los que se miden en tiempo de ejecución, y aquellos que sólo pueden ser estimadas a través de la inspección.

Analizar las ventajas y desventajas entre los atributos de calidad.

Preguntas que debe hacer al considerar los atributos de calidad son:

¿Cuáles son los principales atributos de calidad requeridos para su aplicación? Identificarlos como parte del proceso de diseño.

¿Cuáles son los requisitos clave para hacer frente a estos atributos? ¿Son realmente cuantificable?

¿Cuáles son los criterios de aceptación que indicarán que ha cumplido con los requisitos?

Determinar las preocupaciones transversalesPreocupaciones 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 que pasa a través de mú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 de almacenamiento en caché común que le permite almacenar en caché

los datos en la capa de presentación, la capa de negocio, y la capa de acceso a datos.

La siguiente lista describe algunas de las preocupaciones transversales clave que usted 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 de la granja de servidores 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 aplicaciones de hoy en día. Éstos se refieren a menudo como los estilos arquitectónicos, e incluyen patrones como cliente / servidor, arquitectura en capas, la arquitectura basada en componentes, la arquitectura de bus de mensajes, y la arquitectura orientada a servicios (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 estilos arquitectónicos adecuados para 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. Por lo tanto, una aplicación típica suele utilizar una combinación de más de uno de los estilos descritos en este capítulo.

¿Qué es un estilo arquitectónico?

Un estilo arquitectónico, a veces llamado un patrón arquitectónico, es un conjunto de principios- un patrón de grano grueso que proporciona un marco abstracto para una familia de sistemas. Un estilo arquitectónico 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 conectores que se pueden utilizar en casos de ese estilo, junto con un conjunto de 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ón de 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 oportunidades para 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 estilos arquitectónicos se pueden organizar por su área clave de enfoque. La siguiente tabla muestra las principales áreas de interés y los correspondientes estilos arquitectónicos.

Categoría Estilos Arquitecturacomunicación Arquitectura Orientada a Servicios (SOA), Mensaje de autobusesdespliegue Cliente / Servidor, N-Tier, 3-Tierdominio Dominios impulsados al diseñoestructura 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én contiene una breve descripción de cada estilo. Secciones posteriores de 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ónCliente/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 que exponen bien definidas las interfaces de comunicación.

Dominios impulsados al 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ón de la funcionalidad dentro de una aplicación en 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és de uno o más canales de comunicación, por lo que 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 responsabilidades para una aplicación o sistema en objetos reutilizables y autosuficientes individuales, cada uno con los datos y el comportamiento pertinentes al objeto.

Orientada a ServiciosArquitectura (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 arquitectura de un sistema de software casi nunca se limita a un único estilo arquitectónico, pero es a menudo una combinación de estilos arquitectónicos que componen el sistema completo. 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ón podrían forzarlo a implementar la aplicación utilizando el planteamiento de despliegue de 3 niveles, o un despliegue de más de tres pisos. La capa de presentación puede ser desplegada a la red perimetral, que se encuentra entre la red interna de una organización y 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 modelo de interacción. También puede optar por un estilo de arquitectura SOA, 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ía peticiones a un programa en el servidor. En este caso, es posible implementar el cliente y 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 independientes que exponen a las interfaces de comunicación apropiados. Utilizando el enfoque de diseño orientado a objetos para estos componentes mejorar la reutilización, la capacidad de prueba, y la flexibilidad.

Hay muchos factores que influyen en los estilos arquitectónicos que usted elija. 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 independiente y sistema de servidor, y una red de conexión distribuida. La forma más simple 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, la arquitectura cliente / servidor indica una aplicación de interfaz de usuario de escritorio gráfico que comunica con un servidor de base de datos que contiene gran parte 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 una gama de protocolos y formatos de datos para comunicar la información al cliente.

Hoy en día, algunos ejemplos de la cliente / arquitectura de servidor incluyen en navegador Web programas que se ejecutan en Internet o una intranet basan; Operativo Microsoft Windows® aplicaciones basadas en el sistema que acceden a los servicios de datos en red; aplicaciones que acceden a los almacenes de datos remotos (como lectores de correo electrónico, clientes FTP y herramientas de consulta de base de datos); y herramientas y utilidades que manipulan los sistemas remotos (como herramientas de gestión de sistemas y herramientas de 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 clientes para 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 cliente y el servidor puedan intercambiar sus roles con el fin de distribuir y sincronizar archivos e información a través de múltiples clientes. Se extiende el estilo de cliente / servidor a través de múltiples respuestas a las solicitudes, los datos compartidos, la búsqueda de recursos y capacidad de resistencia a la eliminación de los compañeros.

Los servidores de aplicaciones. Un estilo arquitectónico especializado donde los hosts de servidor y ejecuta aplicaciones y servicios que un cliente ligero accede a través de un navegador o software especializado instalado cliente. Un ejemplo es un cliente de la ejecución de una aplicación que se ejecuta en el servidor a través de un marco como el 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. Debido a que los datos se almacenan sólo en el servidor, el acceso y cambios a los datos son mucho más fáciles de administrar que en otros estilos arquitectónicos.

Facilidad de mantenimiento. Roles y responsabilidades de un sistema de computación se distribuyen entre varios servidores que se conocen entre sí a través de una red. Esto asegura que un cliente permanece inconsciente y no afectado por una reparación de servidores, actualización o reubicación.

Considere el estilo arquitectónico cliente / servidor si su aplicación se basa servidor y 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 estilo arquitectónico de cliente / servidor también es adecuado, al igual que muchos en red estilos, cuando desea centralizar el almacenamiento de datos, copias de

seguridad, y las funciones de gestión, o cuando su aplicación debe ser compatible con diferentes tipos de clientes y diferentes dispositivos. Sin embargo, el cliente / servidor estilo arquitectónico 2-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 estilo arquitectónico de cliente-servidor tiene se convirtió en el más general 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

Arquitectura basada en componentes describe un enfoque de ingeniería de 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.

Contexto no específico. Los componentes están diseñados para funcionar en diferentes entornos y contextos. La información específica, como los datos estatales, se debe pasar a la componente en lugar de ser incluido en o accesible por el componente.

Extensible. Un componente puede extenderse a partir de componentes existentes para 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 tipos más comunes de los componentes utilizados en aplicaciones incluyen componentes de 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ífico de funciones utilizadas en otros componentes. Otros tipos comunes de los componentes son los que son intensivos en recursos, no se accede con frecuencia, y debe activarse con el enfoque just-in-time (JIT) (común en la comunicación remota o escenarios de componentes distribuidos); y en cola componentes cuyas llamadas método puede ser ejecutado de forma asíncrona mediante colas de mensajes y almacenamiento y retransmisión.

Componentes dependen de un mecanismo dentro de la plataforma que proporciona un entorno en el que se pueden ejecutar, que se refiere a la arquitectura como componente de frecuencia. Ejemplos de ello son el modelo de objetos componentes (COM) y el modelo de objetos componentes distribuido (DCOM) de Windows; y CORBA (CORBA) y Enterprise JavaBeans (EJB) en otras plataformas. Arquitecturas de componentes a gestionar los mecanismos de localización de componentes y sus interfaces, pasando mensajes o comandos entre los componentes, y en algunos casos, mantener el estado.

Sin embargo, el componente término se usa a menudo en el sentido más básico de un constituyente parte, elemento o ingrediente. El Microsoft .NET Framework proporciona soporte para la creación de aplicaciones que utilizan un enfoque basado en componentes tales. Por ejemplo, esta guía se describe los componentes de negocio y datos, que son comúnmente clases 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.

Facilidad de desarrollo. Los componentes implementan interfaces bien conocidas para 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 difundir el desarrollo y el coste de mantenimiento a través de varias aplicaciones o sistemas.

Mitigación de complejidad técnica. Componentes mitigar la complejidad a través el uso de un recipiente de componente y sus servicios. Servicios de componente Ejemplo incluir la activación de componentes, la gestión de toda la vida, el método de puesta en cola, concurso completo, y transacciones.

Los patrones de diseño, como el patrón de inyección de dependencia o el patrón Service Locator 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 dominio de la empresa, sus elementos y comportamientos, y las relaciones entre ellos. Su objetivo es permitir que los sistemas de software que son una realización del dominio del negocio subyacente mediante la definición de un modelo de dominio se expresa en el lenguaje de los expertos en los sectores de negocios. El modelo de dominio puede ser visto como 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 negocio que desea modelar, o ser experto en la adquisición de tal conocimiento del negocio. El equipo de desarrollo a menudo trabaja con expertos en el dominio de negocio para modelar el 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 Driven Design, 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 medida que el núcleo del software es el modelo de dominio, que es una proyección directa de este lenguaje común, que permite que el equipo para encontrar rápidamente las lagunas en el software mediante el análisis de la lengua a su alrededor. La creación de una lengua común no es más que un ejercicio de aceptación de la información de los expertos de dominio y aplicarlo. Muy a menudo, los problemas de comunicación dentro de los equipos de desarrollo se deben no sólo a la mala interpretación del lenguaje del dominio, sino también por el hecho de que el lenguaje del dominio es en sí mismo ambiguo. El proceso Driven Design dominio tiene el objetivo no sólo de la aplicación de la lengua que se utiliza, sino también mejorar y perfeccionar el idioma del dominio. Esto a su vez beneficia el software se construye, ya que el modelo es una proyección directa de la lengua dominio.

Con el fin de ayudar a mantener el modelo como una construcción del lenguaje puro y ú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 costo relativamente alto. Mientras Domain Driven Design ofrece muchas ventajas té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 modelo de dominio y las entidades que define a comunicar conocimientos y necesidades de negocios utilizando un lenguaje de dominio de negocio común, sin necesidad de 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én puede ser un método ideal si usted tiene la empresa grande y compleja escenarios 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 de Driven-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 estilo arquitectónico capas ha sido descrito como una pirámide invertida de la reutilización en la que cada capa de agregados de las responsabilidades y abstracciones de la capa directamente debajo de ella. Con estricta capas, componentes en una capa pueden interactuar sólo con componentes en la misma capa o con componentes de la capa directamente debajo de él. Capas más relajada permite que los componentes en una capa para interactuar con componentes en la misma capa o con componentes en cualquier capa inferior.

Las capas de una aplicación pueden residir en el mismo equipo físico (el mismo nivel) o pueden estar distribuidos en equipos independientes (n-tier), y los componentes de cada capa comunicarse con componentes de otras capas a través de interfaces bien definidas. Por ejemplo, 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 aplicado casi en su totalidad a partir de datos de alto nivel marcos de acceso). Para los detalles 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. Arquitectura en capas abstrae la vista del sistema en su conjunto mientras que proporciona suficiente detalle para comprender las funciones y responsabilidades de las capas individuales y la relación entre ellos.

La encapsulación. No hay suposiciones deben hacerse sobre los tipos de datos, 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 es clara. Las capas superiores, como el envío de la capa de presentación comandos 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. Bien definidos los límites de responsabilidad para cada capa, y la garantí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 sistemas de contabilidad y de gestión de clientes (LOB); aplicaciones empresariales basadas en

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 patrones de diseño soporta la arquitectura en capas. Por ejemplo, los patrones de presentación separados abarcan una gama de patrones que el manejo de las interacciones del 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 dominio que incluya reglas de negocio); la vista representa la interfaz de usuario; y el controlador maneja las 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 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 promueven la reutilización. Por ejemplo, en MVC, el controlador puede a menudo ser reutilizados con otros compatibles Vistas a fin de proporcionar una 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 interfaces de capa bien definidos, así como la capacidad de cambiar entre diferentes implementaciones de 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 estilo arquitectónico en capas si tiene capas existentes que son adecuados para su reutilización en otras aplicaciones, ya tiene aplicaciones que exponen a los procesos de

negocio adecuados a través de interfaces de servicio, o su aplicación es compleja y el diseño de alto nivel de las demandas de separación para que los equipos pueden centrarse en diferentes áreas de funcionalidad. El estilo arquitectónico en capas también es apropiado si su aplicación debe ser compatible con diferentes tipos de clientes y diferentes dispositivos, o si desea implementar reglas y procesos de negocio complejos y / o configurables.

Considere la posibilidad de un patrón Presentación Separado si quieres mejorar la capacidad de prueba y mantenimiento simplificado de la funcionalidad de la interfaz de usuario, o si desea separar la tarea de diseñar la interfaz de usuario desde el desarrollo del código de la lógica que lo impulsa. Estos patrones también son apropiados cuando su vista UI no contiene ningún código de procesamiento de solicitudes, y no implementa ninguna lógica empresarial.

Mensaje autobús Estilo Arquitectónico

Arquitectura de bus de mensajes describe el principio de la utilización de un sistema de software que puede recibir y enviar mensajes a través de uno o más canales de comunicación , por lo que las aplicaciones puedan interactuar sin necesidad de conocer los detalles específicos sobre la otra. Es un estilo para el diseño de aplicaciones en las que la interacción entre las aplicaciones se logra mediante el paso de mensajes (por lo general de forma asíncrona) en un bus común. Las implementaciones más comunes de bus de mensajes arquitectura uso, ya sea un router de 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 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:

Comunicaciones de mensajes orientada. Toda la comunicación entre las aplicaciones se 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 las cuales soporta tareas específicas, como parte de un itinerario de etapas múltiples.

Las modificaciones a la lógica de procesamiento. Debido a la interacción con el 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ón con diferentes ambientes. Mediante el uso de un modelo de 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 muchos años. El diseño proporciona una arquitectura conectable que permite insertar aplicaciones en el proceso, o mejorar la escalabilidad uniendo 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 utiliza los servicios para la comunicación entre el bus y los componentes conectados al bus. Un ESB suele proporcionar servicios que transforman los mensajes de un formato a otro, permitiendo a los clientes que utilizan formatos de mensaje incompatibles se comuniquen entre sí.

Internet Service Bus (ISB). Esto es similar a un bus de servicios empresariales, pero con aplicaciones alojadas en la nube en lugar de en una red empresarial. Un concepto básico de ISB es el uso de identificadores uniformes de recursos (URI) y políticas para controlar el enrutamiento de la lógica a través de aplicaciones y servicios en la nube.

Los principales beneficios 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 patrones de comunicación entre las aplicaciones, se puede cambiar fácilmente para que coincida con los cambios en los requisitos de negocio o usuarios, simplemente a través de cambios en la configuración o los parámetros que controlan el enrutamiento.

Acoplamiento débil. Mientras aplicaciones exponen a una interfaz adecuada para la comunicación con el bus de mensajes, no hay dependencia de la aplicación en sí, lo que permite cambios, actualizaciones y reemplazos que exponen la misma interfaz.

Escalabilidad. Varias instancias de la misma aplicación se pueden conectar al bus con el fin de manejar múltiples solicitudes al mismo tiempo.

Simplicidad de aplicación. Aunque una aplicación bus mensaje añade complejidad a la infraestructura, cada aplicación debe ser compatible con una única conexió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ú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á implementando una 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 funcionalidad en segmentos de la misma manera que el estilo en capas, pero con cada segmento siendo un nivel que puede ser situado en un equipo separado físicamente. Evolucionaron a través del enfoque orientado a componentes, generalmente utilizando métodos específicos de 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ésimo sólo tiene que saber cómo manejar una petición de la n + tier día 1, la forma en que transmita esa solicitud en el nivel de n día 1 (si lo hay), y cómo manejar los resultados de la solicitud. La comunicación entre niveles es 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. Cuando se utiliza un enfoque de diseño en capas, una capa se implementa en un nivel si más de un servicio o aplicación depende de la funcionalidad expuesta por la capa.

Un ejemplo de la arquitectura de N-capas / 3-tier es una aplicación web financiera tí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 implementa en los equipos cliente y la capa capa de negocio y acceso a los datos 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 sistemas que permitan el uso de componentes fácilmente escalables, lo que aumenta la disponibilidad.

Considere bien la N-tier o el estilo arquitectónico de 3 niveles, si los requisitos de procesamiento de las capas en la aplicación difieren de tal manera que el procesamiento en una capa podría absorber recursos suficientes para frenar el procesamiento en otras capas, o si los requisitos de seguridad de las capas en la aplicación diferir. Por ejemplo, la capa de presentación no debe almacenar los datos sensibles, si bien esto puede ser almacenada en las capas de negocio y de datos. La N-tier o el estilo arquitectónico de 3 niveles también es apropiado si usted quiere ser capaz de compartir la lógica de negocio entre aplicaciones, y usted tiene el hardware suficiente para asignar el número necesario de servidores para cada nivel.

Considere 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; o una aplicación de Internet donde los requisitos de seguridad no limitan el despliegue de la lógica de negocio en el frente del servidor 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 orientado a objetos considera que un sistema como una serie de objetos que cooperan, en lugar de un conjunto de rutinas o instrucciones de procedimiento. Los objetos son discretos, independiente e imprecisa; se comunican a través de interfaces, llamando a métodos o 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 reducir una operación compleja en una generalización que conserva las características básicas de la operación. Por ejemplo, una interfaz abstracta 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 objetos pueden ser ensambladas a partir de otros objetos, y pueden optar por ocultar estos objetos internos de otras clases ni las exponga las interfaces simples.

Herencia. Los objetos pueden heredar de otros objetos, y el uso de la funcionalidad en el objeto de base o anularlo para implementar un nuevo comportamiento. Por otra parte, la herencia hace que el mantenimiento y las actualizaciones más fá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 variables de otros objetos. Esto hace que sea más fácil para actualizar o reemplazar los objetos, siempre y cuando sus interfaces son compatibles, sin afectar a otros objetos y código.

Polimorfismo. Esto le permite anular el comportamiento de un tipo base que apoya las operaciones en su aplicación mediante la aplicación de los nuevos tipos que son intercambiables con el objeto existente.

El desacoplamiento. Los objetos pueden ser disociados de los consumidores mediante la definición de una interfaz abstracta que implementa el objeto y el consumidor puedan entender. Esto le permite proporcionar implementaciones alternativas sin afectar a los 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 dentro de 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ón más de cerca a los objetos del mundo real, lo que 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. La encapsulación, polimorfismo y abstracción aseguran que un cambio en

la representación de datos no afecta a las interfaces que el objeto expone, lo que limitaría la capacidad de comunicarse e interactuar con otros objetos.

Altamente cohesivo. Al ubicar los métodos y características solo acerca de un objeto, y el uso de diferentes objetos para diferentes conjuntos de características, se puede lograr un alto nivel de cohesión.

Considere el estilo arquitectónico orientado a objetos, si usted quiere modelar su aplicación en función de los objetos del mundo real y las acciones, o si ya tiene objetos y clases que coinciden con el diseño y el funcionamiento adecuados. El estilo orientado a objetos también

es adecuado 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 proporciona como un conjunto de servicios, y la creación de aplicaciones que hacen uso de los servicios de software. Los servicios están débilmente acoplados, ya que utilizan las interfaces basadas en estándares que pueden ser invocados, publicados, y descubrieron. Servicios en SOA se centran en proporcionar un esquema y la interacción basada en mensajes con una aplicación a través de interfaces que son ámbito de la aplicación, y no de componente u objeto-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 pueden estar 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.

Los servicios están débilmente acoplados. Cada servicio es independiente de los demá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, la manipulación procesos de varios pasos, como los sistemas de reserva y tiendas en línea, la exposición de datos o servicios específicos de la industria a través de una extranet, y la creación de mashups que combinan información de múltiples fuentes.

Los principales beneficios de la arquitectura SOA son:

Alineación de dominio. La reutilización de los servicios comunes con interfaces estándar aumenta las oportunidades de negocio y de tecnología y reduce los costos.

Abstracción. Servicios son autónomos y se accede a través de un contrato formal, que proporciona el acoplamiento débil y la abstracción.

Detectabilidad. Los servicios pueden exponer a las descripciones que permiten a otras 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; quieren construir aplicaciones que componen una variedad de servicios en una sola interfaz de usuario; o que está creando Software más Servicios (S + S), Software como Servicio (SaaS), o aplicaciones basadas en la nube. El estilo SOA es adecuado cuando se debe apoyar la comunicación basada en mensajes entre los segmentos de la solicitud y exponer la funcionalidad de una manera independiente de la plataforma, cuando se quiere aprovechar los servicios federados como la autenticación, o si desea exponer servicios que se pueden descubrir a través de directorios y pueden ser utilizados por los clientes que no tienen conocimiento previo de los interfaces.