Guía de Arquitectura N-Capas Orientada al Dominio con .NET 4.0, Resúmenes de Informática Móvil

¡Descarga Guía de Arquitectura N-Capas Orientada al Dominio con .NET 4.0 y más Resúmenes en PDF de Informática Móvil solo en Docsity!

Guía de Arquitectura N-Capas

orientada al Dominio con .NET

(Beta)

César de la Torre Llorente

Unai Zorrilla Castro

Miguel Angel Ramos Barros

Javier Calvarro Nelson

Índice

iv Guía de Arquitectura N-Capas orientada al Dominio con .NET 4.0 (Beta)

vi Guía de Arquitectura N-Capas orientada al Dominio con .NET 4.0 (Beta)

Índice vii

1

Arquitectura Marco .NET

Microsoft Ibérica

1.- INTRODUCCIÓN

Microsoft Ibérica ha detectado en diversos clientes la necesidad de disponer de una

“Guía de Arquitectura base .NET” en español, que sirva para marcar unas líneas

maestras de diseño e implementación a la hora de desarrollar aplicaciones .NET

complejas. Este marco de trabajo común (en muchas empresas denominado “Libro

Blanco”) define un camino para diseñar e implementar aplicaciones empresariales de

envergadura, con un volumen importante de lógica de negocio. Seguir estas guías

ofrece importantes beneficios en cuanto a calidad, estabilidad y especialmente un

incremento en la facilidad del mantenimiento futuro de las aplicaciones, debido al

desacoplamiento entre sus componentes, así como por la homogeneidad y similitudes

de los diferentes desarrollos.

Microsoft Ibérica define el presente „ Libro de Arquitectura Marco ‟ como patrón y

modelo base, sin embargo, en ningún caso este marco debe ser inalterable. Al

contrario, se trata del primer peldaño de una escalera, un acelerador inicial, que debería

ser personalizado y modificado por cada organización que lo adopte, enfocándolo hacia

necesidades concretas, adaptándolo y agregándole funcionalidad específica según el

mercado objetivo, etc.

1.1.- Audiencia del documento

Este documento está dirigido a las personas involucradas en todo el ciclo de vida

de productos software o de aplicaciones corporativas desarrolladas a medida.

Especialmente los siguientes perfiles:

 Arquitecto de Software

 Desarrollador

1.2.- Objetivos de la Arquitectura marco .NET

Este documento pretende describir una arquitectura marco sobre la que desarrollar

las aplicaciones a medida y establece un conjunto de normas, mejores prácticas y guías

de desarrollo para utilizar .NET de forma adecuada y sobre todo homogénea en las

diferentes implementaciones de aplicaciones.

2 Guía de Arquitectura N-Capas orientada al Dominio con .NET 4.0 (Beta)

1.3.- Niveles de la documentación de la Arquitectura marco

.NET

La documentación de esta Arquitectura se diseña en dos niveles principales:

 Nivel lógico de Arquitectura de Software: Este primer nivel lógico, es una

Arquitectura de software agnóstica a la tecnología (donde no se debe especificar

tecnologías concretas de .NET). Para resaltar este nivel, se mostrará el icono:

 Nivel de Implementación de Arquitectura .NET: Este segundo nivel, es la

implementación concreta de Arquitectura .NET, donde se enumerarán las

tecnologías posibles para cada escenario (con versiones concretas) y normalmente

se escogerá una opción y se explicará su implementación. Así mismo, la

implementación de la arquitectura cuenta con una aplicación .NET ejemplo, cuyo

alcance funcional es muy pequeño, pero debe implementar todas y cada una de las

áreas tecnológicas de la Arquitectura marco. Para resaltar este nivel, se mostrará el

icono de .NET al inicio del capítulo:

DESCARGO DE RESPONSABILIDAD :

Queremos insistir en este punto y destacar que la presente propuesta de

„ Arquitectura N-Capas Orientada al Dominio ‟ no es adecuada para cualquier

tipo de aplicaciones, solamente es adecuada para aplicaciones complejas

empresariales con un volumen importante de lógica de negocio y una vida de

aplicación larga, donde es importante implementar conceptos de

desacoplamiento y ciertos patrones DDD. Para aplicaciones pequeñas y

orientadas a datos, probablemente sea más adecuada una aproximación de

Arquitectura más sencilla implementada con tecnologías RAD.

Así mismo, esta guía (y su aplicación ejemplo asociada) es simplemente una

propuesta a tener en cuenta y ser evaluada y personalizada por las

organizaciones y empresas que lo deseen. Microsoft Ibérica no se hace

responsable de problemas que pudieran derivarse de ella.

4 Guía de Arquitectura N-Capas orientada al Dominio con .NET 4.0 (Beta)

Para los usuarios es importante que el sistema responda a la interacción de una

forma fluida, mientras que para los objetivos del negocio es importante que el sistema

cueste poco. Los usuarios pueden querer que se implemente primero una funcionalidad

útil para su trabajo, mientras que el sistema puede tener prioridad en que se implemente

la funcionalidad que permita definir su estructura.

El trabajo del arquitecto es delinear los escenarios y requisitos de calidad

importantes para cada agente así como los puntos clave que debe cumplir y las

acciones o situaciones que no deben ocurrir.

El objetivo final de la arquitectura es identificar los requisitos que producen un

impacto en la estructura del sistema y reducir los riesgos asociados con la construcción

del sistema. La arquitectura debe soportar los cambios futuros del software, del

hardware y de funcionalidad demandada por los clientes. Del mismo modo, es

responsabilidad del arquitecto analizar el impacto de sus decisiones de diseño y

establecer un compromiso entre los diferentes requisitos de calidad así como entre los

compromisos necesarios para satisfacer a los usuarios, al sistema y los objetivos del

negocio.

En síntesis, la arquitectura debería:

 Mostrar la estructura del sistema pero ocultar los detalles.

 Realizar todos los casos de uso.

 Satisfacer en la medida de lo posible los intereses de los agentes.

 Ocuparse de los requisitos funcionales y de calidad.

 Determinar el tipo de sistema a desarrollar.

 Determinar los estilos arquitecturales que se usarán.

 Tratar las principales cuestiones transversales.

Una vez vistas las principales cuestiones que debe abordar el diseño de la

arquitectura del sistema, ahora vamos a ver los pasos que deben seguirse para

realizarlo. En una metodología ágil como Scrum , la fase de diseño de la arquitectura

comienza durante en el pre-juego (Pre-game) o en la fase de Inicio ( Inception ) en RUP,

en un punto donde ya hemos capturado la visión del sistema que queremos construir.

En el diseño de la arquitectura lo primero que se decide es el tipo de sistema o

aplicación que vamos a construir. Los principales tipos son aplicaciones móviles, de

escritorio, RIAs ( Rich Internet Application ), aplicaciones de servicios, aplicaciones

web… Es importante entender que el tipo de aplicación viene determinado por la

topología de despliegue y los requisitos y restricciones indicadas en los requisitos.

La selección de un tipo de aplicación determina en cierta medida el estilo

arquitectural que se va a usar. El estilo arquitectural es en esencia la partición más

básica del sistema en bloques y la forma en que se relacionan estos bloques. Los

principales estilos arquitecturales son Cliente/Servidor, Sistemas de Componentes,

Fundamentos de Arquitectura de Aplicaciones 5

Arquitectura en capas, MVC, N-Niveles, SOA… Como ya hemos dicho, el estilo

arquitectural que elegimos depende del tipo de aplicación, una aplicación que ofrece

servicios lo normal es que se haga con un estilo arquitectural SOA.

Por otra parte, a la hora de diseñar la arquitectura tenemos que entender también

que un tipo de aplicación suele responder a más de un estilo arquitectural. Por ejemplo,

una página web hecha con ASP.NET MVC sigue un estilo Cliente/Servidor pero al

mismo tiempo el servidor sigue un estilo Modelo Vista Controlador.

Tras haber seleccionado el tipo de aplicación y haber determinado los estilos

arquitecturales que más se ajustan al tipo de sistema que vamos a construir, tenemos

que decidir cómo vamos a construir los bloques que forman nuestro sistema. Por ello el

siguiente paso es seleccionar las distintas tecnologías que vamos a usar. Estas

tecnologías están limitadas por las restricciones de despliegue y las impuestas por el

cliente. Hay que entender las tecnologías como los ladrillos que usamos para construir

nuestro sistema. Por ejemplo, para hacer una aplicación web podemos usar la

tecnología ASP.NET o para hacer un sistema que ofrece servicios podemos emplear

WCF.

Cuando ya hemos analizado nuestro sistema y lo hemos fragmentado en partes más

manejables, tenemos que pensar como implementamos todos los requisitos de calidad

que tiene que satisfacer. Los requisitos de calidad son las propiedades no funcionales

que debe tener el sistema, como por ejemplo la seguridad, la persistencia, la usabilidad,

la mantenibilidad, etc. Conseguir que nuestro sistema tenga estas propiedades va a

traducirse en implementar funcionalidad extra, pero esta funcionalidad es ortogonal a la

funcionalidad básica del sistema.

Para tratar los requisitos de calidad el primer paso es preguntarse ¿Qué requisitos de

calidad requiere el sistema? Para averiguarlo tenemos que analizar los casos de uso.

Una vez hemos obtenido un listado de los requisitos de calidad las siguientes preguntas

son ¿Cómo consigo que mi sistema cumpla estos requisitos? ¿Se puede medir esto de

alguna forma? ¿Qué criterios indican que mi sistema cumple dichos requisitos?

Los requisitos de calidad nos van a obligar a tomar decisiones transversales sobre

nuestro sistema. Por ejemplo, cuando estamos tratando la seguridad de nuestro sistema

tendremos que decidir cómo se autentican los usuarios, como se maneja la autorización

entre las distintas capas de nuestro sistema, etc. De la misma forma tendremos que

tratar otros temas como las comunicaciones, la gestión de excepciones, la

instrumentación o el cacheo de datos.

Los procesos software actuales asumen que el sistema cambiará con el paso del

tiempo y que no podemos saber todo a la hora de diseñar la arquitectura. El sistema

tendrá que evolucionar a medida que se prueba la arquitectura contra los requisitos del

mundo real. Por eso, no hay que tratar de formalizar absolutamente todo a la hora de

definir la arquitectura del sistema. Lo mejor es no asumir nada que no se pueda

comprobar y dejar abierta la opción de un cambio futuro. No obstante, sí que existirán

algunos aspectos que podrán requerir un esfuerzo a la hora de modificarlos, donde para

minimizar dichos esfuerzos es especialmente importante el concepto de

desacoplamiento entre componentes. Por ello es vital identificar esas partes de nuestro

sistema y detenerse el tiempo suficiente para tomar la decisión correcta. En síntesis las

claves son:

Fundamentos de Arquitectura de Aplicaciones 7

Dado que usamos una metodología iterativa e incremental para el desarrollo de

nuestra arquitectura, la implementación de la misma debe seguir el mismo patrón. La

forma de hacer esto es mediante pruebas arquitecturales. Estas pruebas son pequeños

desarrollos de parte de la aplicación (Pruebas de Concepto) que se usan para mitigar

riesgos rápidamente o probar posibles vías de maduración de la arquitectura. Una

prueba arquitectural se convierte en una arquitectura candidata que se evalúa contra la

línea base. Si es una mejora, se convierte en la nueva línea base frente a la cual crear y

evaluar las nuevas arquitecturas candidatas. Las preguntas que debemos hacerle a una

arquitectura candidata que surge como resultado de desarrollar una prueba arquitectural

son:

 ¿Introduce nuevos riesgos?

 ¿Soluciona algún riesgo conocido esta arquitectura?

 ¿Cumple con nuevos requisitos del sistema?

 ¿Realiza casos de uso arquitecturalmente significativos?

 ¿Se encarga de implementar algún requisito de calidad?

 ¿Se encarga de implementar alguna parte del sistema transversal?

Los casos de uso importantes son aquellos que son críticos para la aceptación de la

aplicación o que desarrollan el diseño lo suficiente como para ser útiles en la

evaluación de la arquitectura.

En resumen, el proceso de diseño de la arquitectura tiene que decidir qué

funcionalidad es la más importante a desarrollar. A partir de esta decisión tiene que

decidir el tipo de aplicación y el estilo arquitectural, y tomar las decisiones importantes

sobre seguridad, rendimiento… que afectan al conjunto del sistema. El diseño de la

arquitectura decide cuales son los componentes más básicos del sistema y como se

relacionan entre ellos para implementar la funcionalidad. Todo este proceso debe

hacerse paso a paso, tomando solo las decisiones que se puedan comprobar y dejando

abiertas las que no. Esto significa mitigar los riesgos rápidamente y explorar la

implementación de casos de uso que definan la arquitectura.

10 Guía de Arquitectura N-Capas orientada al Dominio con .NET 4.0 (Beta)

Tabla 1.- Estilo Arquitectural Cliente/Servidor

Estilo

Arquitectural

Cliente/Servidor

Descripción

El estilo

cliente/servidor

define una

relación entre dos

aplicaciones en las

cuales una de ellas

(cliente) envía

peticiones a la otra

(servidor fuente de

datos).

Características

 Es un estilo para sistemas distribuidos.

 Divide el sistema en una aplicación cliente, una

aplicación servidora y una red que las conecta.

 Describe una relación entre el cliente y el servidor en

la cual el primero realiza peticiones y el segundo

envía respuestas.

 Puede usar un amplio rango de protocolos y formatos

de datos para comunicar la información.

Principios

Clave

 El cliente realiza una o más peticiones, espera por las

respuestas y las procesa a su llegada.

 El cliente normalmente se conecta solo a uno o a un

número reducido de servidores al mismo tiempo.

 El cliente interactúa directamente con el usuario, por

ejemplo a través de una interfaz gráfica.

Estilos Arquitecturales 11

 El servidor no realiza ninguna petición al cliente.

 El servidor envía los datos en respuesta a las

peticiones realizadas por los clientes conectados.

 El servidor normalmente autentifica y verifica

primero al usuario y después procesa la petición y

envía los resultados.

Beneficios

 Más seguridad ya que los datos se almacenan en el

servidor que generalmente ofrece más control sobre

la seguridad.

 Acceso centralizado a los datos que están

almacenados en el servidor lo que facilita su acceso y

actualización.

 Facilidad de mantenimiento ya que los roles y las

responsabilidades se distribuyen entre los distintos

servidores a través de la red lo que permite que un

cliente no se vea afectado por un error en un servidor

particular.

Cuando usarlo

 La aplicación se basa en un servidor y soportará

múltiples clientes.

 La aplicación está normalmente limitada a un uso

local y área LAN controlada.

 Estás implementando procesos de negocio que se

usarán a lo largo de toda tu organización.

 Quieres centralizar el almacenamiento, backup y

mantenimiento de la aplicación.

 La aplicación debe soportar distintos tipos de clientes

y distintos dispositivos.