Gua de Arquitectura N-Capas

Orientada al Dominio con .NET 4.0

Autores

Csar de la Torre Llorente (Microsoft)

Unai Zorrilla Castro (Plain Concepts)

Javier Calvarro Nelson (Microsoft)

Miguel ngel Ramos Barroso (Microsoft)

Autores parciales

Cristian Manteiga Pacios (Plain Concepts)

Fernando Corts Hierro (Plain Concepts)

Israel Garca Mesa (Microsoft)

Colaboradores

Pierre Milet LLobet (Microsoft) Ricardo Minguez Pablos (Rido) (Microsoft)

Hadi Hariri (MVP) (JetBrains)

Roberto Gonzalez (MVP) (Renacimiento)

Juan Cid (Avanade)

Lalo Steinmann (Microsoft)

GUA DE ARQUITECTURA N-CAPAS ORIENTADA AL DOMINIO CON

.NET 4.0

No est permitida la reproduccin total o parcial de este libro, ni su tratamiento informtico, ni la

transmisin de ninguna forma o por cualquier medio, ya sea electrnico, mecnico, por fotocopia,

por registro u otros mtodos, sin el permiso previo y por escrito de los titulares del Copyright.

Dirjase a Cesar de la Torre Llorente (cesardl@microsoft.com), si exclusivamente para el

uso interno de su empresa/organizacin, desea reutilizar el contenido de esta obra y

personalizarlo hacia una Arquitectura corporativa concreta. Dirjase a CEDRO (Centro

Espaol de Derechos Reprogrficos, www.cedro.org) si necesita fotocopiar o escanear algn

fragmento de esta obra.

DERECHOS RESERVADOS 2010, por Microsoft Ibrica S.R.L.

EDITADO por Krasis Consulting, S. L. www.krasis.com

ISBN: 978-84-936696-3-8

Depsito Legal: M-13152-2010

Impreso en Espaa-Printed in Spain

Agradecimientos

Csar de la Torre

Dedico este libro especialmente a mi familia, que ha sufrido el trabajo de innumerables fines de semana trabajando en ello. Tambin lo dedico a nuestra

compaa Microsoft y especficamente a Microsoft Ibrica, porque con este trabajo

hemos aunado esfuerzos de diferentes reas muy complementarias. One-Microsoft!.

Lo siguiente son los comentarios de mi familia sobre este libro ;-) Mi mujer, Marta:

A ver si lo acabas que tenemos pendiente muchas cosas de la casa o irnos de escapadas ms a menudo

Mi hija Erika (9 aos): Papi, trabajas mucho y esto no se entiende nada Mi hijo Adrin (6 aos):

No s.., jugamos a la XBOX?

Unai Zorrilla

A Lucia y Maria, mi familia, por su inmerecida paciencia con mis maratonianas jornadas y mis continuos viajes

Javier Calvarro

A mi abuela Teresa. Te dedico todo el esfuerzo y dedicacin que he puesto en estas pginas.

Miguel ngel Ramos Barroso Para Rosario; mi compaera, mi amiga, mi amor, mi aliento, mi vida. Slo quince aos juntos, y an nos queda mucho por compartir.

iv

v

Contenido

AGRADECIMIENTOS ........................................................................................... III

CONTENIDO ........................................................................................................ IV

PRLOGOS......................................................................................................... XIII

ARQUITECTURA MARCO .NET MICROSOFT IBRICA ............................ XIX

Introduccin ............................................................................................................................... xix 1.- Audiencia del documento ......................................................................................................... xix 1.1.- Objetivos de la Arquitectura Marco .NET ........................................................................ xix 1.2.- Niveles de la documentacin de la Arquitectura marco .NET .................................... xx 1.3.- Aplicacin Ejemplo en CODEPLEX ...................................................................................... xxi 1.4.-

FUNDAMENTOS DE ARQUITECTURA DE APLICACIONES ......................... 1

EL PROCESO DE DISEO DE LA ARQUITECTURA ........................................ 7

Identificar los objetivos de la iteracin .................................................................................. 9 1.- Seleccionar los casos de uso arquitecturalmente importantes ....................................... 9 2.- Realizar un esquema del sistema ........................................................................................... 10 3.- Identificar los principales riesgos y definir una solucin .................................................. 15 4.- Crear Arquitecturas Candidatas ............................................................................................ 16 5.- aspectos de domain driven design ....................................................................................... 18 6.-

El lenguaje ubicuo .......................................................................................................................... 19 6.1.- Prcticas que ayudan a conseguir un buen modelo de dominio. ................................ 20 6.2.-

Behavior Driven Development (BDD) ............................................................................... 20 6.2.1.- Test Driven Development (TDD) ........................................................................................ 20 6.2.2.-

ARQUITECTURA MARCO N-CAPAS ............................................................... 21

Arquitectura de Aplicaciones en N-Capas .......................................................................... 21 1.- Capas vs. Niveles (Layers vs. Tiers) ....................................................................................... 21 1.1.- Capas .................................................................................................................................................. 22 1.2.- Principios Base de Diseo a seguir ...................................................................................... 27 1.3.-

Principios de Diseo SOLID ................................................................................................. 27 1.3.1.- Otros Principios clave de Diseo.......................................................................................... 28 1.3.2.-

Orientacin a tendencias de Arquitectura DDD (Domain Driven Design) ........ 29 1.4.- DDDD (Distributed Domain Driven Design) ................................................................. 32 1.5.-

Arquitectura Marco N-Capas con Orientacin al Dominio .................................................. 32 2.-

vi

Capas de Presentacin, Aplicacin, Dominio e Infraestructura .................................. 33 2.1.- Arquitectura marco N-Capas con Orientacin al Dominio ......................................... 34 2.2.- Desacoplamiento entre componentes .................................................................................. 50 2.3.- Inyeccin de dependencias e Inversin de control .......................................................... 53 2.4.- Mdulos ............................................................................................................................................ 58 2.5.- Subdivisin de modelos y contextos de trabajo ................................................................ 61 2.6.- Bounded Contexts ........................................................................................................................ 62 2.7.- Relaciones entre contextos ....................................................................................................... 63 2.8.-

Shared Kernel ................................................................................................................................. 63 2.8.1.- Customer/Supplier ....................................................................................................................... 63 2.8.2.- Conformista .................................................................................................................................... 64 2.8.3.- Anti-corruption Layer................................................................................................................. 64 2.8.4.- Separate ways ................................................................................................................................. 65 2.8.5.- Open Host ....................................................................................................................................... 65 2.8.6.-

Implementacin de bounded contexts en .NET ............................................................... 66 2.9.- Cmo partir un modelo de Entity Framework? ......................................................... 67 2.9.1.- Relacin entre bounded contexts y ensamblados ....................................................... 68 2.9.2.-

Visin de tecnologas en Arquitectura N-Layer ............................................................... 69 2.10.- Implementacin de Estructura de Capas en Visual Studio 2010 ................................. 69 2.11.- Aplicacin ejemplo N-Layer DDD con .NET 4.0 ............................................................. 70 2.12.- Diseo de la solucin de Visual Studio ................................................................................. 71 2.13.- Arquitectura de la Aplicacin con Diagrama Layer de VS.2010 ................................ 79 2.14.- Implementacin de Inyeccin de Dependencias e IoC con UNITY ........................ 80 2.15.-

Introduccin a Unity.................................................................................................................... 82 2.15.1.- Escenarios usuales con Unity .................................................................................................. 83 2.15.2.- Patrones Principales ..................................................................................................................... 84 2.15.3.- Mtodos principales..................................................................................................................... 84 2.15.4.- Registro Configurado de tipos en Contenedor ............................................................. 85 2.15.5.- Inyeccin de dependencias en el constructor ................................................................. 85 2.15.6.- Inyeccin de Propiedades (Property Setter) .................................................................... 88 2.15.7.- Resumen de caractersticas a destacar de Unity ............................................................ 89 2.15.8.- Cundo utilizar Unity .................................................................................................................. 89 2.15.9.-

Orientacin a Arquitectura EDA (Event Driven Architecture) .................................... 90 3.- Acceso Dual a Fuentes de Datos ......................................................................................... 92 4.- Nveles Fsicos en despliegue (Tiers) .................................................................................... 94 5.-

CAPA DE INFRAESTRUCTURA DE PERSISTENCIA DE DATOS ................. 99

Capa de Infraestructura de Persistencia de Datos ........................................................... 99 1.- Arquitectura y Diseo lgico de la Capa de Persistencia de Datos 1 ....................... 100 2.-

Elementos de la Capa de Persistencia y Acceso a Datos............................................ 101 2.1.- Repositorios (Repository pattern) ..................................................................................... 101 2.1.1.- Modelo de Datos ........................................................................................................................ 105 2.1.2.- Tecnologa de Persistencia (O/RM, etc.) .......................................................................... 106 2.1.3.- Agentes de Servicios Distribuidos externos .................................................................. 106 2.1.4.-

Otros patrones de acceso a datos ...................................................................................... 106 2.2.- Active Record .............................................................................................................................. 107 2.2.1.-

Table Data Gateway .................................................................................................................. 107 2.2.2.- Data Mapper ................................................................................................................................. 108 2.2.3.- Lista de patrones para las capas de Persistencia de Datos ...................................... 108 2.2.4.-

Pruebas en la capa de Infraestructura de Persistencia de Datos................................. 109 3.- Consideraciones generales de diseo del acceso a datos ............................................. 112 4.-

Referencias Generales .............................................................................................................. 115 4.1.- Implementacin en .NET de la Capa de Persistencia de Datos ................................ 116 5.-

Opciones de tecnologa para la Capa de Persistencia de Datos .............................. 117 5.1.- Seleccin de Tecnologa de Acceso a Datos ................................................................... 117 5.2.-

Otras consideraciones tecnolgicas ................................................................................. 118 5.2.1.- Cmo obtener y persistir objetos desde el almacn de datos ............................ 120 5.2.2.-

Posibilidades de Entity Framework en la Capa de Persistencia ................................ 121 5.3.- Qu nos aporta Entity Framework 4.0? ......................................................................... 121 5.3.1.-

Creacin del Modelo de Datos Entidad-Relacin de Entity-Framework ............. 122 5.4.- Plantillas T4 de generacin de entidades POCO/Self-Tracking ................................ 126 5.5.- Tipos de datos Entidades Self-Tracking ........................................................................... 129 5.6.- Importancia de situar las Entidades en la Capa del Dominio .................................... 130 5.7.-

Separacin del Core de plantillas T4 STE ..................................................................... 134 5.7.1.- Plantillas T4 de Persistencia de Datos y conexin a las fuentes de datos ............ 135 5.8.- Implementacin de Repositorios con Entity Framework y Linq to Entities ........ 135 5.9.- Implementacin de Patrn Repositorio............................................................................. 136 5.10.-

Clase Base para los Repositories (Patrn Layer Supertype) ................................ 138 5.10.1.- Uso de Generics en implementacin de clase base Repository ......................... 139 5.10.2.- Interfaces de Repositorios e importancia en el desacoplamiento entre 5.10.3.-

componentes de capas ............................................................................................................................. 144 Implementacin de Pruebas Unitarias e Integracin de Repositorios ................... 146 5.11.- Conexiones a las fuentes de datos ...................................................................................... 151 5.12.-

El Pool de Conexiones a fuentes de datos ................................................................... 152 5.12.1.- Estrategias para gestin de errores originados en fuentes de datos ...................... 154 5.13.- Agentes de Servicios Externos (Opcional) ....................................................................... 155 5.14.- Referencias de tecnologas de acceso a datos ................................................................. 155 5.15.-

CAPA DE MODELO DE DOMINIO .................................................................. 157

El Dominio ................................................................................................................................. 157 1.- Arquitectura y Diseo lgico de la Capa de Dominio ................................................... 158 2.-

Aplicacin ejemplo: Caractersticas de negocio del Modelo de Dominio ejemplo 2.1.-a Disear 159

Elementos de la Capa de Dominio ...................................................................................... 161 2.2.- Entidades del Dominio ............................................................................................................. 161 2.2.1.- Patrn Objeto-Valor (Value-Object pattern) .............................................................. 168 2.2.2.- Agregados (Patrn Aggregate) ........................................................................................... 171 2.2.3.- Contratos/Interfaces de Repositorios dentro de la Capa de Dominio ............. 173 2.2.4.- SERVICIOS del Modelo de Dominio ................................................................................. 174 2.2.5.- Patrn ESPECIFICACION (SPECIFICATION) ............................................................ 180 2.2.6.-

Consideraciones de Diseo de la Capa de Dominio ................................................... 185 2.3.- EDA y Eventos del Dominio para articular reglas de negocio .................................. 187 2.4.-

Eventos del Dominio Explcitos ........................................................................................... 188 2.4.1.-

viii

Testing y Pruebas Unitarias cuando utilizamos Eventos del Dominio ................ 188 2.4.2.- Implementacin de la Capa de Dominio con .NET 4.0 ................................................. 188 3.-

Implementacin de Entidades del Dominio...................................................................... 189 3.1.- Generacin de entidades POCO/IPOCO con plantillas T4 de EF ......................... 194 3.2.- Lgica del Dominio en las Clases de Entidades .............................................................. 195 3.3.- Situacin de Contratos/Interfaces de Repositorios en Capa de Dominio ........... 196 3.4.- Implementacin de Servicios del Dominio ....................................................................... 198 3.5.-

SERVICIOS del Dominio como coordinadores de procesos de Negocio ...... 199 3.5.1.- Patrn ESPECIFICACION (SPECIFICATION pattern) .............................................. 201 3.6.-

Uso del patrn SPECIFICATION ....................................................................................... 201 3.6.1.- Implementacin del patrn SPECIFICATION .............................................................. 202 3.6.2.- Especificaciones compuestas por operadores AND y OR ........................................ 205 3.6.3.-

Implementacin de pruebas en la capa del dominio ..................................................... 207 3.7.-

CAPA DE APLICACIN .................................................................................... 211

Capa de Aplicacion .................................................................................................................. 211 1.- Arquitectura y Diseo lgico de la Capa de Aplicacin ................................................ 212 2.-

Proceso de diseo de capa de Aplicacin ......................................................................... 214 2.1.- La importancia del desacoplamiento de la Capa de Aplicacin con respecto a 2.2.-

Infraestructura ......................................................................................................................................... 215 Componentes de la Capa de Aplicacin ............................................................................ 215 3.-

Servicios de Aplicacin ............................................................................................................. 215 3.1.- Desacoplamiento entre SERVICIOS de APLICACION y REPOSITORIOS ....... 219 3.2.-

Patrn Unidad de Trabajo (UNIT OF WORK) ......................................................... 220 3.2.1.- Servicios Workflows de Capa de Aplicacin (Opcional) ......................................... 222 3.2.2.-

Errores y anti-patrones en la Capa de Aplicacin ......................................................... 224 3.3.- Aspectos de Diseo relacionados con la Capa de Aplicacin .................................. 226 3.4.-

Autenticacin ................................................................................................................................ 226 3.4.1.- Autorizacin .................................................................................................................................. 227 3.4.2.- Cache ............................................................................................................................................... 228 3.4.3.- Gestin de Excepciones .......................................................................................................... 229 3.4.4.- Logging, Auditora e Instrumentalizacin ......................................................................... 229 3.4.5.- Validaciones ................................................................................................................................... 230 3.4.6.- Aspectos de despliegue de la Capa de Aplicacin ....................................................... 231 3.4.7.- Concurrencia y Transacciones ............................................................................................. 231 3.4.8.-

Mapa de patrones posibles a implementar en la capa de Aplicacin ...................... 232 3.5.- Implementacin en .NET de Capa de Aplicacion ........................................................... 234 4.-

Implementacin de Servicios de Capa de Aplicacin ................................................... 235 4.1.- Desacoplamiento e Inyeccin de Dependencias entre Servicios de Aplicacin y 4.1.1.-

Repositorios mediante IoC de UNITY ............................................................................................. 237 Implementacin de Transacciones y UoW en Servicios de Capa de Aplicacin245 4.2.-

Transacciones en .NET ............................................................................................................ 245 4.2.1.- Implementacin de Transacciones en la Capa de Servicios del Dominio ........ 249 4.2.2.- Modelo de Concurrencia en actualizaciones y transacciones ................................ 250 4.2.3.- Tipos de Aislamiento de Transacciones ........................................................................... 252 4.2.4.-

Implementacin de pruebas en la capa de Aplicacin .................................................. 257 4.3.-

CAPA DE SERVICIOS DISTRIBUIDOS............................................................ 259

Situacin en Arquitectura N-Capas .................................................................................... 259 1.- Arquitecturas Orientadas a Servicios y Arquitecturas en N-Capas (N-Layer) ....... 261 2.- Situacin de Arquitectura N-Layer con respecto a Aplicaciones aisladas y a 3.-

Servicios SOA ................................................................................................................................. 262 Qu es SOA? ........................................................................................................................... 263 4.- Pilares de SOA (Service Orientation Tenets) .................................................................. 264 5.- Arquitectura interna de los Servicios SOA ...................................................................... 268 6.- Pasos de Diseo de la Capa de Servicios .......................................................................... 269 7.- Tipos de Objetos de Datos a comunicar .......................................................................... 270 8.- Consumo de Servicios Distribuidos basado en Agentes ............................................... 274 9.-

Interoperabilidad ................................................................................................................ 276 10.- Rendimiento .......................................................................................................................... 277 11.- Comunicacin Asncrona vs. Sncrona ............................................................................ 278 12.- REST vs. SOAP ...................................................................................................................... 279 13.-

Consideraciones de Diseo para SOAP ........................................................................... 282 13.1.- Consideraciones de Diseo para REST ............................................................................. 283 13.2.-

Introduccin a SOAP y WS-* ........................................................................................... 284 14.- Especificaciones WS-* ......................................................................................................... 284 15.- Introduccin a REST ............................................................................................................ 288 16.-

La URI en REST ........................................................................................................................... 288 16.1.- Simplicidad ..................................................................................................................................... 289 16.2.- URLs lgicas versus URLs fsicas .......................................................................................... 290 16.3.- Caractersticas base de Servicios Web REST .................................................................. 290 16.4.- Principios de Diseo de Servicios Web REST ................................................................ 291 16.5.-

ODATA: Open Data Protocol ......................................................................................... 292 17.- Reglas globales de Diseo para sistemas y servicios SOA ....................................... 295 18.- Implementacin de la Capa de Servicios Distribuidos con WCF .NET 4.0 .......... 300 19.- Opciones tecnolgicas ........................................................................................................ 301 20.-

Tecnologa WCF ........................................................................................................................ 301 20.1.- Tecnologa ASMX (Servicios Web ASP.NET)................................................................. 302 20.2.- Seleccin de tecnologa ............................................................................................................ 303 20.3.- Tipos de Despliegue de Servicios WCF ........................................................................... 303 20.4.-

Introduccin a WCF (Windows Communication Foundation) ............................... 307 21.- El ABC de Windows Communication Foundation ..................................................... 309 21.1.- Definicin e implementacin de un servicio WCF ....................................................... 312 21.2.- Hospedaje del servicio (Hosting) y configuracin (Bindings) ..................................... 316 21.3.- Configuracin de un servicio WCF ..................................................................................... 318 21.4.-

Implementacin de Capa de Servicios WCF en Arquitectura N-Layer ................. 320 22.- Tipos de Objetos de Datos a Comunicar con Servicios WCF ................................ 322 23.- Cdigo de Servicio WCF publicando lgica de Aplicacin y Dominio .................. 325 24.-

Desacoplamiento de objetos de capas internas de la Arquitectura, mediante 24.1.-UNITY 325

Gestin de Excepciones en Servicios WCF..................................................................... 327 24.2.- Tipos de alojamiento de Servicios WCF y su implementacin ................................ 327 24.3.-

Despliegue y Monitorizacin de Servicios WCF en Windows Server AppFabric25.- 332

x

Instalacin y configuracin de Windows Server AppFabric. ..................................... 333 25.1.- Despliegue de servicios WCF en Windows Server AppFabric. ............................... 336 25.2.-

Identidad de acceso a B.D. SQL Server e Impersonacin de nuestra aplicacin 25.2.1.-WCF 338

Monitorizacin de servicios WCF desde la consola de Windows Server 25.3.-AppFabric en IIS Manager. .................................................................................................................. 340 Referencias Globales DE WCF y Servicios ................................................................... 343 26.-

CAPA DE PRESENTACIN .............................................................................. 345

Situacin en Arquitectura N-Capas .................................................................................... 345 1.- Necesidades de invertir en la interfaz de usuario ........................................................... 346 2.- Necesidad de arquitecturas en la capa de presentacin ............................................... 348 3.-

Acoplamiento entre capas ...................................................................................................... 348 3.1.- Bsqueda de rendimiento. ...................................................................................................... 349 3.2.- Pruebas unitarias ......................................................................................................................... 349 3.3.-

Patrones de Arquitectura en la capa de Presentacin ................................................... 350 4.- Patrn MVC (Modelo Vista Controlador) ....................................................................... 350 4.1.- El modelo ....................................................................................................................................... 352 4.2.- Las vistas ........................................................................................................................................ 352 4.3.- El controlador .............................................................................................................................. 353 4.4.- Patrn MVP (Modelo Vista Presentador) ......................................................................... 353 4.5.- Patrn MVVM (Model-View-ViewModel) ...................................................................... 355 4.6.- Visin global de MVVM en la arquitectura orientada a dominios ............................ 356 4.7.- Patrones de diseo utilizados en MVVM ........................................................................... 357 4.8.-

El patrn Comandos (Command) ...................................................................................... 357 4.8.1.- El patrn Observador (Observer) ...................................................................................... 360 4.8.2.-

Implementacin de Capa DE Presentacin ....................................................................... 362 5.- Arquetipos, Tecnologas UX y Patrones de Diseo relacionados .......................... 364 5.1.- Implementacin de Patrn MVVM con WPF 4.0 ........................................................... 366 5.2.-

Justificacin de MVVM .............................................................................................................. 367 5.2.1.- Diseo con patrn Model-View-ViewModel (MVVM) ............................................. 371 5.2.2.-

Implementacin del patrn MVVM en Silverlight 4.0 .................................................. 377 5.3.- Modelo de programacin asncrona .................................................................................. 378 5.3.1.- Modelo de validaciones ............................................................................................................ 380 5.3.2.-

Beneficios y Consecuencias del uso de MVVM .............................................................. 381 5.4.- Validacin de datos en la interfaz (WPF) .......................................................................... 382 6.- Validacin de datos en la interfaz de Usuario (Silverlight) ............................................ 385 7.- Implementacin con asp.net MVC 2.0 ............................................................................... 387 8.-

Fundamentos de ASP.NET MVC.......................................................................................... 388 8.1.- El pipeline de ASP.NET MVC ................................................................................................ 388 8.2.- Un ejemplo completo: Actualizacin de un cliente ....................................................... 390 8.3.- Otros aspectos de la aplicacin ............................................................................................ 393 8.4.-

CAPAS DE INFRAESTRUCTURA TRANSVERSAL ....................................... 395

Capas de Infraestructura Transversal ................................................................................. 395 1.- Situacin de Infraestructura Transversal en la Arquitectura ........................................ 396 2.-

Consideraciones Generales de Diseo .............................................................................. 396 3.- Aspectos Transversales.......................................................................................................... 398 4.-

Seguridad en la aplicacin: Autenticacin y Autorizacin ........................................... 399 4.1.- Autenticacin ................................................................................................................................ 399 4.1.1.- Autorizacin .................................................................................................................................. 400 4.1.2.- Arquitectura de Seguridad basada en Claims .............................................................. 401 4.1.3.-

Cache .............................................................................................................................................. 406 4.2.- Gestin de Configuracin ....................................................................................................... 408 4.3.- Gestin de Excepciones .......................................................................................................... 409 4.4.- Registro/Logging y Auditoras ................................................................................................ 410 4.5.- Instrumentalizacin .................................................................................................................... 410 4.6.- Gestin de Estados .................................................................................................................... 411 4.7.- Validacin....................................................................................................................................... 411 4.8.-

Implementacin en .NET de Aspectos Transversales .................................................... 413 5.- Implementacin en .NET de Seguridad basada en Claims ........................................ 413 5.1.-

STS y ADFS 2.0 ............................................................................................................................ 413 5.1.1.- Pasos para implementar Orientacin a Claims con WIF ....................................... 416 5.1.2.- Beneficios de la Orientacin a Claims, WIF y ADFS 2.0 ........................................ 419 5.1.3.-

Implementacin de Cache en plataforma .NET .............................................................. 419 5.2.- Implementacin de Cache-Servidor con Microsoft AppFabric-Cache ............. 419 5.2.1.- Implementacin de AppFabric-Cache en aplicacin ejemplo DDD NLayerApp 5.2.2.-

426 Implementacin de Cache en Nivel Cliente de Aplicaciones N-Tier (Rich-5.2.3.-

Client y RIA) ................................................................................................................................................. 432 Implementacin de Logging/Registro .................................................................................. 433 5.3.- Implementacin de Validacin ............................................................................................... 433 5.4.-

ARQUETIPOS DE APLICACIN ..................................................................... 435

Arquetipo Aplicacin Web ................................................................................................. 437 1.- Arquetipo Aplicaciones RIA................................................................................................ 439 2.- Arquetipo Aplicacin rica de escritorio (Rich Client) ................................................. 441 3.- Arquetipo Servicio Distribuido - SOA ............................................................................... 443 4.- Arquetipo Aplicaciones Mviles .......................................................................................... 446 5.- Arquetipo Aplicaciones Cloud Computing .................................................................... 448 6.- Arquetipo Aplicaciones OBA (Office Business Applications) ...................................... 452 7.- Arquetipo Aplicacin de negocio basada en Sharepoint ............................................. 455 8.-

ARQUITECTURA Y PATRONES EN CLOUD-COMPUTING PAAS ........ 459

Arquitectura de Aplicaciones en la nube ........................................................................... 460 1.- Escenarios de Arquitectura en la nube .............................................................................. 463 2.- Escenario Bsico: Migracin directa de aplicacin On-Premise a la Nube ............... 463 3.-

Arquitectura Lgica (Escenario Bsico) ............................................................................. 463 3.1.- Por qu hacer uso de Windows Azure? .......................................................................... 464 3.2.- Breve introduccin a la plataforma Windows Azure ................................................... 465 3.3.-

Procesamiento en Windows Azure ................................................................................. 468 3.3.1.- Implementacin de escenario bsico en plataforma Windows Azure .................. 469 3.4.-

xii

Pasos para migrar Aplicacin ejemplo NLayerApp a Windows Azure (Escenario 3.5.-Bsico en la nube) .................................................................................................................................. 472

Migracin de Base de Datos SQL Server ........................................................................ 473 3.5.1.- Cambio de cadena de conexin de ADO.NET / EF .................................................. 483 3.5.2.- Migracin de proyectos en hosting de IIS a Azure ...................................................... 484 3.5.3.- Despliegue en la nube de Windows Azure en Internet ........................................... 491 3.5.4.- Gestin de imgenes en Web: Cambio de almacn local (disco) a Windows 3.5.5.-

Azure Blobs ................................................................................................................................................... 496 Seguridad en Windows Azure .............................................................................................. 496 3.5.6.- Otros puntos a tener en cuenta al migrar aplicaciones a Windows Azure .... 497 3.5.7.-

Escenario Avanzado: Aplicacin Escalable en Cloud-Computing ................................ 498 4.- Arquitectura Lgica (Escenario Avanzado en la nube) ............................................... 499 4.1.- Patrn CQRS (Command and Query Responsibility Segregation) ......................... 499 4.2.-

Por qu CQRS? ......................................................................................................................... 502 4.2.1.-

CONCLUSIONES ............................................................................................... 505

xiii

Prlogos

Prlogo de Enrique Fernandez-Laguilhoat

(Director Divisin de Plataforma y Desarrollo en Microsoft Ibrica)

No es por casualidad que el sector de la informtica ha imitado al de la construccin

utilizando las apelaciones de Arquitecto y de Arquitectura. Al igual que en las grandes

obras de construccin, para garantizar el xito en el desarrollo de un aplicativo software se

requiere antes que nada de una buena definicin de la estructura que se va a seguir, de los

distintos elementos o mdulos que se van a construir y de cmo interactan entre ellos de

forma segura y eficaz. Un mal trabajo de arquitectura lleva en muchos casos al fracaso del

proyecto, y al contrario, si el arquitecto de software hace bien su cometido, el producto

resultante tender a ser robusto, el tiempo y esfuerzo para desarrollarlo ms bajo, y algo

muy importante, la facilidad para ampliar o extender el desarrollo en un futuro ser mucho

ms alta.

Esta gua viene a cubrir un rea muy importante en el mundo del desarrollo. De la mano

de un grupo notable de profesionales de software y liderados por Csar de la Torre, uno de

los principales Arquitectos de Software con los que cuenta Microsoft, se ofrece una visin

exhaustiva y sistemtica de cmo deber abordarse un desarrollo en capas utilizando la

tecnologa .Net. Y adems, lo hace en perfecto Castellano viniendo a saldar una vieja deuda

que Microsoft Ibrica tena con los desarrolladores de habla hispana. Si desarrollar con el

framework .Net siempre ha sido fcil y altamente productivo, la llegada de esta gua ofrece adems una ayuda altamente estructurada que facilita la definicin de la arquitectura

y el modelado de la aplicacin.

Ha sido un placer ver durante varios meses la ilusin (y las largas horas de trabajo) que

tanto Csar como los que le ha ayudado con su contribucin han invertido en esta gua. Por

mi parte, quiero agradecer su trabajo y esfuerzo y reconocer el alto grado de calidad que

tiene el producto resultante. Y estoy seguro de que el lector sabr agradecerlo tambin

sacando el mayor provecho de esta gua en sus nuevos retos de desarrollo.

xiv

Prlogo de Jos Murillo (Developer Solution Specialist, Microsoft DPE)

Los grandes proyectos de software empresariales fracasan habitualmente. Es una

afirmacin dura, pero admitmoslo, es la cruda realidad con lo que todos los que llevamos

aos en el mundo del desarrollo de aplicaciones estamos familiarizados.

La industria del desarrollo de software apenas tiene 60 aos. Durante este tiempo hemos ido aprendiendo a pasar de la arena al ladrillo, del ladrillo a los bloques

prefabricados, pero todas estas tcnicas de construccin perfectamente vlidas para una

casa son insuficientes e intiles para grandes edificaciones. Si intentamos aplicarlas para

estos macro-proyectos, el tiempo de desarrollo se multiplica exponencialmente o el edificio

se derrumba al primer temblor o prueba de carga de los usuarios.

Qu est fallando? Para m no hay ninguna duda, Gestin del Ciclo de Vida del

Desarrollo y Arquitectura Empresarial de Aplicaciones. Tan importante como en la

Arquitectura tradicional son el diseo, las estructuras y los clculos de carga, en el mundo

del desarrollo de software lo es la Arquitectura Software y de Sistemas. Es la disciplina que

nos ensea como tenemos que combinar los bloques y tecnologas existentes para formar

aplicaciones slidas y duraderas. Este rol por desgracia est muy poco presente en las

empresas actuales, donde cualquier buen programador con el paso del tiempo y una vez hay

que reconocerle sus mritos pasados, es promocionado a Jefe de Proyectos. Pero qu demonios tiene que ver una cosa con la otra?

Este libro ofrece justamente las pautas, guas, recomendaciones y buenas prcticas para

que los Arquitectos Software puedan disear aplicaciones empresariales sin reinventar la

rueda, utilizando patrones existentes y buenas prcticas comprobadas. Es capaz de aterrizar

con efectividad conceptos abstractos y multitud de las ltimas tecnologas Microsoft en

recomendaciones concretas para esos nuevos Arquitectos .NET.

De aqu mi reconocimiento y gracias por su trabajo a mi compaero y amigo Cesar de la

Torre. Conozco perfectamente el gran esfuerzo personal que ha realizado para hacer

realidad este proyecto, que estoy convencido repercutir en la mejora de la calidad de las

aplicaciones empresariales que se pongan en marcha siguiendo sus recomendaciones.

Igualmente gracias al resto de colaboradores sin cuya ayuda este libro hubiese acabado con

Cesar.

Prologo de Aurelio Porras (Developer Solution Specialist, Microsoft DPE)

He tenido la oportunidad de participar en el desarrollo de alguna que otra aplicacin de

cierta envergadura y recuerdo gratamente esas reuniones en los inicios de los proyectos

donde esbozbamos con cajas y flechas el esqueleto arquitectnico, detectbamos patrones

y etiquetbamos cualquier elemento del diagrama con las ltimas tecnologas disponibles

que nos ayudaran a implementar de la mejor forma posible la funcionalidad requerida sin

tener que reinventar la rueda. En esas discusiones arquitectnicas solan aflorar los tpicos

enfrentamientos sobre el nivel de complejidad de la arquitectura de la aplicacin que se

quera implementar: por un lado los partidarios de montar una arquitectura ms sencilla,

aprovechando bibliotecas de cdigo e implementaciones de patrones ya construidas, para

producir lgica de negocio enseguida y presentar resultados lo antes posible, dando ms

libertad al desarrollador a la hora de emplear las tecnologas; y por el otro los partidarios de

construir una arquitectura ms compleja, construyendo bibliotecas e implementando

patrones a medida de la aplicacin, para acelerar la produccin de la lgica de negocio ms

adelante aunque se presentaran resultados ms tarde, elevando el nivel de abstraccin para

evitar que el desarrollador tuviese que tomar decisiones tecnolgicas. Era interesante ver

cmo los simplistas increpaban los complicados el esfuerzo malgastado al construir arcos de iglesia innecesarios que los fabricantes de la infraestructura tecnolgica en su

siguiente versin haran obsoleta y el hasto que producan al desarrollador de la lgica de

negocio que en ocasiones dejaba de ser un programador y se converta en un mero

configurador de la arquitectura; y los complicados reprendan a los simplistas por la cantidad de cdigo duplicado que tiraban a la basura y el esfuerzo en coordinacin que

malgastaban para evitar esos problemas de duplicidad funcional al haber dado tanta libertad

al desarrollador. S, suena al abuelo Cebolleta contando batallitas, pero es que era reuniones

muy entretenidas.

El resultado final de esas discusiones y de algunas caitas era una serie de decisiones

arquitectnicas que determinaban la infraestructura tecnolgica que se empleara para

construir la aplicacin, las relaciones con sistemas externos, la organizacin del cdigo en

capas, las bibliotecas ya disponibles a usar y las que habra que desarrollar a medida, entre

otras cosas. Recuerdo particularmente cmo tratbamos de desacoplar partes de la

aplicacin para facilitar su futura evolucin, hasta donde el estado del arte de la tecnologa

nos dejaba llegar por aquel entonces, para poder modificar o extender la lgica de negocio

sin tener que tocar todos los mdulos o poder intercambiar uno de los sistemas externos, el

servidor de aplicaciones o la base de datos sin muchos problemas.

Pero esas decisiones arquitectnicas no slo estaban condicionadas por factores tcnicos

como las infraestructuras tecnolgicas, los lenguajes de programacin o las herramientas de

desarrollo; sino tambin por factores propiamente relacionados con el desarrollo de un

proyecto software como su presupuesto y duracin, sus hitos y entregables, la experiencia

del equipo de desarrollo, el conocimiento del negocio y aquellos porque-ses que tienen

todos los proyectos. Al final la arquitectura poda sufrir esos indeseados tijeretazos por

decisiones de proyecto. Pues bien, lamentablemente, tambin he tenido la oportunidad de comprobar cmo

determinadas decisiones arquitectnicas pueden condenar el futuro de grandes aplicaciones.

xvi

Conozco el caso de una aplicacin financiera que logra adaptarse a los cambios del negocio

muy rpidamente gracias al alto nivel de abstraccin que proporciona su arquitectura; el

propio usuario es capaz de modificar la lgica de la aplicacin a travs de una herramienta

visual y programando en un pseudo-lenguaje de negocio; el problema es que la capacidad

de integracin en lnea con otros sistemas est muy limitada porque est construida sobre

tecnologas obsoletas y su acoplamiento con stas es tal, que el coste de migracin a ltimas

tecnologas es demasiado alto y no se puede justificar desde el punto de vista del negocio;

especialmente si tenemos en cuenta que la aplicacin sigue funcionando como un reloj

suizo y, siguiendo la mxima de esta nuestra industria, si funciona no lo toques. Tambin

conozco otra aplicacin financiera bien desacoplada del servidor de aplicaciones y de la

base de datos y que resulta relativamente sencillo actualizar tecnolgicamente, pero que no

cuid la organizacin del cdigo y la lgica de negocio est tan intrincada en las diferentes

capas de la aplicacin que no resulta tan gil adaptarla a los cambios como al negocio le

gustara, y agilizarla supondra reescribir las tres cuartas partes de la aplicacin;

impensable, casi un nuevo proyecto. Seguramente las dos aplicaciones se idearon as por las

circunstancias particulares que rodeaban a sus respectivos proyectos, pero est claro que las

decisiones arquitectnicas tomadas en su momento han afectado negativamente al

mantenimiento evolutivo de esas dos aplicaciones, que, como ya se prevea desde un

principio, tendran una larga duracin en el entorno de produccin.

sta es la madre del cordero que ha motivado esta gua. Naturalmente el estado del arte

de la tecnologa ha cambiado bastante, las tendencias arquitectnicas, las capacidades de las

infraestructuras tecnolgicas modernas, las novedades en los lenguajes de programacin y

las nuevas herramientas de desarrollo ayudan mucho a construir arquitecturas dbilmente

acopladas para facilitar el mantenimiento evolutivo de las aplicaciones; pero si adems

concebimos la arquitectura de la aplicacin teniendo presente en primer lugar la

importancia de su futura evolucin, para adaptarse con facilidad a los cambios de negocio y

para incorporar las ltimas tecnologas sustituyendo a las que van quedando anticuadas,

estaremos cerca de construir una gran aplicacin de negocio con garantas de una vida

saludable.

Y en esto ahonda la gua, en construir una arquitectura que desacople la lgica del

negocio de la tecnologa utilizada para construir la aplicacin de forma que puedan

evolucionar independientemente la una de la otra. Y no slo habla de los pjaros y las

flores, sino que se remanga a un nivel de detalle tcnico que nos ilustrar en las ltimas

tecnologas .NET y herramientas de desarrollo de Microsoft y su aplicacin en grandes

aplicaciones de negocio, indicando cundo usar qu tecnologa y porqu, e incluyendo

adems el cdigo de una aplicacin de ejemplo siguiendo los preceptos indicados a lo largo

la gua.

Por todo este material esclarecedor, agradezco a Csar el esfuerzo que ha realizado

liderando esta iniciativa que seguro ayudar a arquitectos y desarrolladores a plantear

arquitecturas de aplicaciones con una visin ms holstica, y extiendo el agradecimiento a

los autores y los colaboradores que han participado en su elaboracin. Enhorabuena por el

resultado.

Israel Garcia Mesa

(Consultor - Microsoft Services)

Actualmente disponemos de un amplio abanico de opciones tecnolgicas que podemos

usar en nuestros proyectos y que cubren muchas necesidades que se han ido detectando a lo

largo de los aos. La experiencia que tenemos en Microsoft Ibrica es que esta variedad de

alternativas no resuelve toda la problemtica de los proyectos en nuestros clientes. El

anlisis que hemos realizado y que continuamos realizando para mejorar da a da nos ha

proporcionado una serie de conclusiones que queremos compartir en esta gua.

Reflexiones de Arquitectura

El desarrollo de un proyecto de construccin de software es un proceso en el que

intervienen muchos factores y por ello es importante contar con las herramientas

adecuadas. Actualmente hay disponibles muchas opciones tecnolgicas que nos ayudan

a componer nuestras soluciones, pero sin embargo no mitigan las principales

problemticas de un proyecto:

Necesidades de adaptacin a cambios en los proyectos (requerimientos

funcionales y tcnicos), que pueden tener un alto impacto en lo que a esfuerzo se

refiere.

Incertidumbre a la hora de escoger y utilizar la tecnologa que mejor encaja en

cada escenario.

Integracin con sistemas heredados que no tienen un alineamiento claro con los

requerimientos de proyecto.

Estas y otras situaciones pueden afectar al desarrollo de los proyectos y aumentar la

posibilidad de que se manifiesten nuevos riesgos que impacten al proyecto. Con el fin de

mitigar estos riesgos es recomendable:

La metodologa de trabajo debe adaptarse a nuestro equipo, a nuestro tipo de

proyecto y a nuestro cliente, puesto que ser nuestra tctica para alcanzar nuestro

objetivo y hay que tener en cuenta todos los detalles. Por tanto, es importante

escoger un mtodo de trabajo adaptado al contexto del proyecto en donde hay que

considerar el tipo de solucin y el equipo de trabajo.

Considerar un modelo de arquitectura que satisfaga las necesidades conocidas y

con un bajo nivel de acoplamiento, lo que facilitar su adaptabilidad. En este punto

pueden elegirse distintas opciones a la hora de plantear el sistema, pero seguir el

modelo plantado por el Diseo Dirigido al Dominio (DDD) nos puede ayudar a

seguir el planteamiento ms adecuado.

El diseo de una solucin, aparte de ser un proceso incremental, puede ser un proceso a

realizar desde distintos enfoques hasta completar la visin de la solucin. De la experiencia

xviii

recogida en los distintos proyectos que nos hemos desarrollado, hemos visto tiles algunos

planteamientos que resumimos a continuacin:

Las soluciones, sean del tamao que sean, nacen de un diseo global en donde los

aspectos tcnicos no son relevantes (podramos hablar de diseo conceptual) y

posteriormente disear las partes de la solucin a medida que nos tengamos que ir

enfocando en cada una de ellas. Con este modelo poco a poco nos iremos

acercando a los detalles de la implementacin desacoplando el diseo, reduciendo

la complejidad y la posibilidad de que un problema tcnico pueda afectar al resto

de la solucin.

As mismo, ser necesario conjugar el diseo del modelo lgico con el o los

modelos fsicos, siendo lo ideal que un planteamiento condicione lo menos posible

al otro. Este tipo de planteamientos facilita la reutilizacin y la adaptabilidad de la

solucin a distintos escenarios.

Siempre estar la tentacin de construir la solucin entorno a la idea de que la

tecnologa resolver nuestros problemas, y nos parecer que es un camino corto a nuestros

objetivos. Sin embargo, podemos descubrir que no es el camino ms rpido ya que cuando

un diseo no puede crecer y/o evolucionar porque o bien nos requiere un alto esfuerzo o no

controlamos el impacto de dichos cambios, entonces es cuando la tecnologa no aporta

valor a la solucin y puede convertirse en un problema.

Adicionalmente hay una serie de herramientas muy tiles a la hora de construir una

solucin y que nos ayudan tambin a la hora de abordar cambios en la implementacin y en

el diseo de la misma:

Desarrollo de Pruebas: disponer de pruebas unitarias y funcionales

automatizadas nos ayudar a conocer la estabilidad de nuestra solucin, y por lo

tanto determinar si algn cambio ha podido afectar a la solucin y en qu punto.

Refactorizacin: plantear e implementar cambios en la solucin mediante

tcnicas de refactoring es una manera eficiente que nos ayuda a controlar el

impacto de los mismos. Complementar la refactorizacin con el uso de pruebas

ayuda a reducir riesgos, por lo que son dos herramientas perfectamente

complementarias.

Comunicacin: una buena comunicacin dentro del equipo, reduce la posibilidad

de trabajar de manera ineficiente o incluso duplicar funcionalidad. Adems es un

instrumento til en nuestra relacin con el cliente ayudndonos a poner en comn

expectativas, detectar nuevos requerimientos o posibles riesgos rpida y gilmente.

Estas conclusiones que pueden parecer lgicas y sin embargo difciles de llevar a cabo,

son la razn por la queremos compartir el conocimiento presente en esta gua con el fin de

que nuestra experiencia pueda ser til en los proyectos y la tecnologa se convierta en esa

herramienta que hace ms fcil nuestro trabajo.

Arquitectura Marco .NET

Microsoft Ibrica

INTRODUCCIN 1.-

Microsoft Ibrica ha detectado en mltiples clientes y partners la necesidad de disponer de una Gua de Arquitectura base .NET en espaol, que sirva para marcar unas lneas maestras de diseo e implementacin a la hora de desarrollar aplicaciones

.NET complejas y con una vida y evolucin de larga duracin. Este marco de trabajo

comn (en muchas empresas denominado Libro Blanco) define un camino para disear e implementar aplicaciones empresariales de envergadura, con un volumen

importante de lgica de negocio. Seguir estas guas 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

a realizar.

Microsoft Ibrica define el presente Libro de Arquitectura Marco como patrn y modelo base, sin embargo, en ningn caso este marco debe ser inalterable. Al

contrario, se trata del primer peldao de una escalera, un acelerador inicial, que debera

ser personalizado y modificado por cada organizacin que lo adopte, enfocndolo hacia

necesidades concretas, adaptndolo y agregndole funcionalidad especfica segn el

mercado objetivo, etc.

Audiencia del documento 1.1.-

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

Objetivos de la Arquitectura Marco .NET 1.2.-

Este documento pretende describir una arquitectura marco sobre la que desarrollar

las aplicaciones a medida y establece un conjunto de normas, mejores prcticas y guas

de desarrollo para utilizar .NET de forma adecuada y, sobre todo, homognea.

xx

Niveles de la documentacin de la Arquitectura marco 1.3.-

.NET

La documentacin de esta arquitectura se disea en dos niveles principales:

Nivel lgico de Arquitectura de Software: Este primer nivel lgico, es una Arquitectura de software agnstica a la tecnologa, donde no se

especifican tecnologas concretas de .NET. Para resaltar este nivel, se

mostrar el icono:

Nivel de Implementacin de Arquitectura .NET: Este segundo nivel, es la implementacin concreta de Arquitectura .NET, donde se enumerarn

las tecnologas posibles para cada escenario con versiones concretas;

normalmente se escoger una opcin y se explicar su implementacin. As

mismo, la implementacin de la arquitectura cuenta con una aplicacin

.NET ejemplo, cuyo alcance funcional es muy pequeo, pero debe

implementar todas y cada una de las reas tecnolgicas de la Arquitectura

marco. Para resaltar este nivel, se mostrar el icono de .NET al inicio del

captulo:

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 lgica de negocio y una vida y evolucin de aplicacin de larga duracin, donde es importante

implementar conceptos de desacoplamiento y ciertos patrones DDD. Para

aplicaciones pequeas y orientadas a datos, probablemente sea ms adecuada

una aproximacin de arquitectura ms sencilla implementada con tecnologas

RAD.

As mismo, esta gua (y su aplicacin ejemplo asociada) es simplemente una

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

organizaciones y empresas que lo deseen. Microsoft Ibrica no se hace responsable de problemas que pudieran derivarse de ella.

Aplicacin Ejemplo en CODEPLEX 1.4.-

Es fundamental destacar que simultneamente a la elaboracin de este libro/gua de

Arquitectura, tambin hemos desarrollado una aplicacin ejemplo, que implementa los

patrones expuestos en esta gua, con las ltimas tecnologas actuales de Microsoft (Ola .NET 4.0).

As mismo, la mayora de los snippets de cdigo mostrados en este libro, son

extractos de cdigo precisamente de esta Aplicacin ejemplo.

Esta aplicacin ejemplo est publicada en CODEPLEX como cdigo OSS y se

puede descargar desde la siguiente URL:

http://microsoftnlayerapp.codeplex.com/

En CODEPLEX disponemos no solo del cdigo fuente de la aplicacin ejemplo,

tambin de cierta documentacin sobre requerimientos (tecnologas necesarias como

Unity 2.0, PEX & MOLES, WPF Toolkit, Silverlight 4 Tools for Visual Studio 2010, Silverlight 4.0 Toolkit, AppFabric, etc., links desde donde descargarlas en Internet,

etc.) y de una pgina de Discusiones/Foro, algo muy interesante para poder colaborar

con la comunidad, y poder tambin presentarnos preguntas, ideas, propuestas de

evolucin, etc.:

xxii

La aplicacin ejemplo implementa los diferentes patrones de Diseo y Arquitectura

DDD, pero con las ltimas tecnologas Microsoft. Tambin dispone de varios clientes

(WPF, Silverlight, ASP.NET MVC) y otros a ser aadidos como OBA y Windows

Phone 7.0, etc.

Es importante resaltar que la funcionalidad de la aplicacin ejemplo, es

lgicamente, bastante sencilla, pues lo que se quiere resaltar es la Arquitectura, no

implementar un volumen grande de funcionalidad que complique el seguimiento y

entendimiento de la Arquitectura.

La Capa de presentacin y las diferentes implementaciones son simplemente un

rea ms de la arquitectura y no son precisamente el core de esta gua de referencia, donde nos centramos ms en capas relativas al servidor de componentes (Capa del

Dominio, de Aplicacin, Infraestructura de acceso a datos, son sus respectivos

patrones). Aun as, se hace tambin una revisin de los diferentes patrones en capa de

presentacin (MVC, M-V-VM, etc.) y como implementarlos con diferentes

tecnologas.

Aqu mostramos algunas pantallas capturadas de la aplicacin ejemplo:

Cliente Silverlight 4.0

Silverlight Lista de Clientes

Silverlight Transicin de Silverlight

Silverlight Vista de Cliente

xxiv

Cliente WPF 4.0

WPF Vista de Lista de Clientes

WPF Vista de Cliente

WPF Transferencias Bancarias

Cliente ASP.NET MVC

MVC Transferencias Bancarias

xxvi

MVC Vista de Lista de Clientes

Por ltimo, resaltar que tanto la aplicacin como todo el cdigo fuente e dicha

aplicacin, lo hemos elaborado en ingls, para poder ser aprovechada por toda la

comunidad, a nivel mundial y no solo en Espaol.

Recomendamos bajar de Internet esta aplicacin ejemplo e irla investigando en paralelo segn se lee la presente gua/libro de Arquitectura, especialmente cuando se

est leyendo los apartados de implementacin marcados con el siguiente logo de .NET:

1

CAPTULO

El diseo de la arquitectura de un sistema es el proceso por el cual se define una

solucin para los requisitos tcnicos y operacionales del mismo. Este proceso define

qu componentes forman el sistema, cmo se relacionan entre ellos, y cmo mediante

su interaccin llevan a cabo la funcionalidad especificada, cumpliendo con los criterios

de calidad indicados como seguridad, disponibilidad, eficiencia o usabilidad.

Durante el diseo de la arquitectura se tratan los temas que pueden tener un impacto

importante en el xito o fracaso de nuestro sistema. Algunas preguntas que hay que

hacerse al respecto son:

En qu entorno va a ser desplegado nuestro sistema?

Cmo va a ser nuestro sistema puesto en produccin?

Cmo van a utilizar los usuarios nuestro sistema?

Qu otros requisitos debe cumplir el sistema? (seguridad, rendimiento, concurrencia, configuracin)

Qu cambios en la arquitectura pueden impactar al sistema ahora o una vez desplegado?

Para disear la arquitectura de un sistema es importante tener en cuenta los intereses

de los distintos agentes que participan. Estos agentes son los usuarios del sistema, el

propio sistema y los objetivos del negocio. Cada uno de ellos impone requisitos y

restricciones que deben ser tenidos en cuenta en el diseo de la arquitectura y que

pueden llegar a entrar en conflicto, por lo que se debe alcanzar un compromiso entre

los intereses de cada participante.

Para los usuarios es importante que el sistema responda a la interaccin de una

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

Fundamentos de

Arquitectura de

Aplicaciones

1

2 Gua de Arquitectura N-Capas Orientada al Dominio con .NET 4.0

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 construccin

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 diseo 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 sntesis, la arquitectura debera:

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 usarn.

Tratar las principales cuestiones transversales.

Una vez vistas las principales cuestiones que debe abordar el diseo de la

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

realizarlo. En una metodologa gil como Scrum, la fase de diseo 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 visin del sistema que queremos construir.

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

aplicacin que vamos a construir. Los principales tipos son aplicaciones mviles, de

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

web Es importante entender que el tipo de aplicacin viene determinado por la topologa de despliegue y los requisitos y restricciones indicadas en los requisitos.

La seleccin de un tipo de aplicacin determina en cierta medida el estilo

arquitectural que se va a usar. El estilo arquitectural es en esencia la particin ms

bsica del sistema en bloques y la forma en que se relacionan estos bloques. Los

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

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

Fundamentos de Arquitectura de Aplicaciones 3

arquitectural que elegimos depende del tipo de aplicacin. Una aplicacin que ofrece

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

Por otra parte, a la hora de disear la arquitectura tenemos que entender tambin

que un tipo de aplicacin suele responder a ms de un estilo arquitectural. Por ejemplo,

una pgina 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 aplicacin y haber determinado los estilos

arquitecturales que ms se ajustan al tipo de sistema que vamos a construir, tenemos

que decidir cmo vamos a construir los bloques que forman nuestro sistema. Por ello el

siguiente paso es seleccionar las distintas tecnologas que vamos a usar. Estas

tecnologas estn limitadas por las restricciones de despliegue y las impuestas por el

cliente. Hay que entender las tecnologas como los ladrillos que usamos para construir

nuestro sistema. Por ejemplo, para hacer una aplicacin web podemos usar la

tecnologa 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 ms

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 bsica 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 Cmo 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 cmo se autentican los usuarios, como se maneja la autorizacin

entre las distintas capas, etc. De la misma forma tendremos que tratar otros temas como

las comunicaciones, la gestin de excepciones, la instrumentacin 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 disear 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 opcin de un cambio futuro. No obstante, s que existirn

algunos aspectos que podrn requerir un esfuerzo a la hora de realizar modificaciones.

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 decisin correcta. En sntesis las

claves son:

4 Gua de Arquitectura N-Capas Orientada al Dominio con .NET 4.0

Construir hasta el cambio ms que hasta el final.

Utilizar herramientas de modelado para analizar y reducir los riesgos.

Utilizar modelos visuales como herramienta de comunicacin.

Identificar las decisiones clave a tomar.

A la hora de crear la arquitectura de nuestro sistema de forma iterativa e

incremental, las principales preguntas a responder son:

Qu partes clave de la arquitectura representan el mayor riesgo si las diseo mal?

Qu partes de la arquitectura son ms susceptibles de cambiar?

Qu partes de la arquitectura puedo dejar para el final sin que ello impacte en el desarrollo del sistema?

Cules son las principales suposiciones que hago sobre la arquitectura y como las verifico?

Qu condiciones pueden provocar que tenga que cambiar el diseo?

Como ya hemos dicho, los procesos modernos se basan en adaptarse a los cambios

en los requisitos del sistema y en ir desarrollando la funcionalidad poco a poco. En el

plano del diseo de la arquitectura, esto se traduce en que definiremos la arquitectura

del sistema final poco a poco. Podemos entenderlo como un proceso de maduracin,

como el de un ser vivo. Primero tendremos una arquitectura a la que llamaremos

lnea base y que es una visin del sistema en el momento actual del proceso. Junto

a esta lnea base tendremos una serie de arquitecturas candidatas que sern el

siguiente paso en la maduracin de la arquitectura. Cada arquitectura candidata

incluye el tipo de aplicacin, la arquitectura de despliegue, el estilo arquitectural, las

tecnologas seleccionadas, los requisitos de calidad y las decisiones transversales. Las

preguntas que deben responder las arquitecturas candidatas son:

Qu suposiciones he realizado en esta arquitectura?

Qu requisitos explcitos o implcitos cumple esta arquitectura?

Cules son los riesgos tomados con esta evolucin de la arquitectura?

Qu medidas puedo tomar para mitigar esos riesgos?

En qu medida esta arquitectura es una mejora sobre la lnea base o las otras arquitecturas candidatas?

Fundamentos de Arquitectura de Aplicaciones 5

Dado que usamos una metodologa iterativa e incremental para el desarrollo de

nuestra arquitectura, la implementacin de la misma debe seguir el mismo patrn. La

forma de hacer esto es mediante pruebas arquitecturales. Estas pruebas son pequeos

desarrollos de parte de la aplicacin (Pruebas de Concepto) que se usan para mitigar

riesgos rpidamente o probar posibles vas de maduracin de la arquitectura. Una

prueba arquitectural se convierte en una arquitectura candidata que se evala contra la

lnea base. Si es una mejora, se convierte en la nueva lnea 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 algn riesgo conocido esta arquitectura?

Cumple con nuevos requisitos del sistema?

Realiza casos de uso arquitecturalmente significativos?

Se encarga de implementar algn requisito de calidad?

Se encarga de implementar alguna parte del sistema transversal?

Los casos de uso importantes son aquellos que son crticos para la aceptacin de la

aplicacin o que desarrollan el diseo lo suficiente como para ser tiles en la

evaluacin de la arquitectura.

En resumen, el proceso de diseo de la arquitectura tiene que decidir qu

funcionalidad es la ms importante a desarrollar. A partir de esta decisin tiene que

decidir el tipo de aplicacin y el estilo arquitectural, y tomar las decisiones importantes

sobre seguridad, rendimiento que afectan al conjunto del sistema. El diseo de la arquitectura decide cuales son los componentes ms bsicos 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 rpidamente y explorar la

implementacin de casos de uso que definan la arquitectura.

7

CAPTULO

En el marco de la ingeniera del software y del ALM, el proceso de diseo de la

arquitectura juega un papel muy importante. La diferencia entre un buen proceso de

diseo arquitectural y uno malo puede suponer la diferencia entre el fracaso o xito de

nuestro proyecto. En el diseo de la arquitectura tratamos los temas ms importantes a

la hora de definir nuestro sistema, es decir, creamos un molde bsico de nuestra

aplicacin. Dentro del proceso de diseo de la arquitectura se decide:

Qu tipo de aplicacin se va a construir. (Web, RIA, Rich Client)

Qu estructura lgica va a tener la aplicacin (N-Capas, Componentes)

Qu estructura fsica va a tener la aplicacin (Cliente/Servidor, N-Tier)

Qu riesgos hay que afrontar y cmo hacerlo. (Seguridad, Rendimiento, Flexibilidad)

Qu tecnologas vamos a usar (WCF,WF,WPF, Silverlight, Entity Framework, etc.)

Para realizar todo este proceso partiremos de la informacin que ha generado el

proceso de captura de requisitos, ms detalladamente, esta informacin es:

Casos de uso o historias de usuario.

Requisitos funcionales y no funcionales.

Restricciones tecnolgicas y de diseo en general.

El proceso de Diseo de

la Arquitectura

2

8 Gua de Arquitectura N-Capas Orientada al Dominio con .NET 4.0

Entorno de despliegue propuesto.

A partir de esta informacin deberemos generar los artefactos necesarios para que

los programadores puedan implementar correctamente el sistema. Como mnimo, en el

proceso de diseo de la arquitectura debemos definir:

Casos de uso significativos a implementar.

Riesgos a mitigar y cmo hacerlo.

Arquitecturas candidatas a implementar.

Como ya hemos dicho, el diseo de la arquitectura es un proceso iterativo e

incremental. En el diseo de la arquitectura repetimos 5 pasos hasta completar el

desarrollo del sistema completo. Los pasos que repetimos y la forma ms clara de

verlos es esta:

Figura 1.- Diseo de Arquitectura

A continuacin vamos a examinar en ms detalle cada uno de estos pasos para

comprender qu debemos definir y dejar claro en cada uno de ellos.

El proceso de Diseo de la Arquitectura 9

IDENTIFICAR LOS OBJETIVOS DE LA ITERACIN 1.-

Los objetivos de la iteracin son el primer paso para dar forma a la arquitectura de

nuestro sistema. En este punto lo importante es analizar las restricciones que tiene

nuestro sistema en cuanto a tecnologas, topologa de despliegue, uso del sistema, etc En esta fase es muy importante marcar cuales van a ser los objetivos de la arquitectura,

tenemos que decidir si estamos construyendo un prototipo, realizando un diseo

completo o probando posibles vas de desarrollo de la arquitectura. Tambin hay que

tener en cuenta en este punto a las personas que forman nuestro equipo. El tipo de

documentacin a generar as como el formato depender de si nos dirigimos a otros

arquitectos, a desarrolladores, o a personas sin conocimientos tcnicos.

El objetivo de esta fase del proceso de diseo de la arquitectura es entender por

completo el entorno que rodea a nuestro sistema. Esto nos permitir decidir en qu

centraremos nuestra actividad en las siguientes fases del diseo y determinar el

alcance y el tiempo necesarios para completar el desarrollo. Al trmino de esta fase

deberemos tener una lista de los objetivos de la iteracin, preferiblemente con planes

para afrontarlos y mtricas para determinar el tiempo y esfuerzo que requerir

completarlos. Tras esta fase es imprescindible tener una estimacin del tiempo que

invertiremos en el resto del proceso.

SELECCIONAR LOS CASOS DE USO 2.-ARQUITECTURALMENTE IMPORTANTES

El diseo de la arquitectura es un proceso dirigido por el cliente y los riesgos a

afrontar, esto significa que desarrollaremos primero los casos de uso (funcionalidad)

que ms valor tengan para el cliente y mitigaremos en primer lugar los riesgos ms

importantes que afronte nuestra arquitectura (requisitos de calidad). La importancia de

un caso de uso la valoraremos segn los siguientes criterios:

Lo importante que es el caso de uso dentro de la lgica de negocio: Esto vendr dado por la frecuencia de utilizacin que tendr el caso de uso en el sistema en

produccin o el valor que aporte esa funcionalidad al cliente.

El desarrollo del caso de uso implica un desarrollo importante de la arquitectura: Si el caso de uso afecta a todos los niveles de la arquitectura es un

firme candidato a ser prioritario, ya que su desarrollo e implementacin

permitirn definir todos los niveles de la arquitectura aumentando la estabilidad

de la misma.

El desarrollo del caso de uso implica tratar algn requisito de calidad: Si el caso de uso requiere tratar temas como la seguridad, la disponibilidad o la tolerancia

a fallos del sistema, es un caso de uso importante ya que permite tratar los

aspectos horizontales del sistema a la vez que se desarrolla la funcionalidad.

10 Gua de Arquitectura N-Capas Orientada al Dominio con .NET 4.0

Lo que se adapte el caso de uso a los objetivos de la iteracin: A la hora de seleccionar los casos de uso que vamos a implementar tenemos que tener en

cuenta lo que se ajustan a los objetivos que nos hemos marcado para la

iteracin. No vamos a escoger casos de uso que desarrollen mucho el conjunto

del sistema si nos hemos marcado como objetivo de la iteracin reducir bugs o

mitigar algn riesgo dado.

Es muy importante tener claro que no se debe tratar de disear la arquitectura del

sistema en una sola iteracin. En esta fase del proceso de diseo analizamos todos los

casos de uso y seleccionamos solo un subconjunto, el ms importante

arquitecturalmente y procedemos a su desarrollo. En este punto, solo definimos los

aspectos de la arquitectura que conciernen a los casos de uso que hemos seleccionado y

dejamos abiertos el resto de aspectos para futuras iteraciones. Es importante recalcar

que puede que en una iteracin no definamos por completo algn aspecto del sistema,

pero lo que tenemos que tener claro es que debemos intentar minimizar el nmero de

cambios en futuras iteraciones. Esto no significa que no debamos asumir que el software evoluciona, sino que cuando desarrollemos un aspecto del sistema no nos atemos a una solucin especfica sino que busquemos una solucin genrica que

permita afrontar los posibles cambios en futuras iteraciones. En definitiva, todo esto se

resume en dar pasos cortos pero firmes.

Es interesante a la hora de desarrollar el sistema tener en cuenta las distintas

historias de usuario, sistema y negocio. Las historias de usuario, sistema y negocio son

pequeas frases o prrafos que describen aspectos del sistema desde el punto de vista

del implicado. Las historias de usuario definen como los usuarios utilizarn el sistema,

las historias de sistema definen los requisitos que tendr que cumplir el sistema y como

se organizar internamente y las historias de negocio definen como el sistema cumplir

con las restricciones de negocio.

Desmenuzar los casos de uso en varias historias de usuario, sistema y negocio

nos permitir validar ms fcilmente nuestra arquitectura asegurndonos de que cumple

con las historias de usuario, sistema y negocio de la iteracin.

REALIZAR UN ESQUEMA DEL SISTEMA 3.-

Una vez que estn claros los objetivos de la iteracin y la funcionalidad que

desarrollaremos, podemos pasar a su diseo. Llegados a este punto, el primer paso es

decidir qu tipo de aplicacin vamos a desarrollar. El tipo de aplicacin que elegiremos

depender de las restricciones de despliegue, de conectividad, de lo compleja que sea la

interfaz de usuario y de las restricciones de interoperabilidad, flexibilidad y tecnologas

que imponga el cliente. Cada tipo de aplicacin nos ofrece una serie de ventajas e

inconvenientes, el arquitecto tiene que escoger el tipo de aplicacin que mejor se ajuste

a las ventajas que espera que tenga su sistema y que presente menos inconvenientes.

Los principales tipos de aplicaciones que desarrollaremos son:

El proceso de Diseo de la Arquitectura 11

Aplicaciones para dispositivos mviles: Se trata de aplicaciones web con una interfaz adaptada para dispositivos mviles o aplicaciones de usuario

desarrolladas para el terminal.

Aplicaciones de escritorio: Son las aplicaciones clsicas que se instalan en el equipo del usuario que la vaya a utilizar.

RIA (Rich Internet Applications): Se trata de aplicaciones que se ejecutan dentro del navegador gracias a un plug-in y que ofrecen una mejor respuesta

que las aplicaciones web y una interfaz de calidad similar a las aplicaciones de

usuario con la ventaja de que no hay que instalarlas.

Servicios: Se trata de aplicaciones que exponen una funcionalidad determinada en forma de servicios web para que otras aplicaciones los consuman.

Aplicaciones web: Son aplicaciones que se consumen mediante un navegador y que ofrecen una interfaz de usuario estndar y completamente interoperable.

A modo de resumen y gua, la siguiente tabla recoge las principales ventajas y

consideraciones a tener en cuenta para cada tipo de aplicacin:

Tabla 1.- Ventajas y consideraciones tipos de aplicacin

Tipo de

aplicacin Ventajas Consideraciones

Aplicaciones para

dispositivos mviles

Sirven en escenarios sin conexin o con conexin

limitada.

Se pueden llevar en dispositivos de mano.

Ofrecen alta disponibilidad y fcil acceso a los

usuarios fuera de su

entorno habitual.

Limitaciones a la hora de interactuar con la

aplicacin.

Tamao de la pantalla reducido.

Aplicaciones de

escritorio

Aprovechan mejor los recursos de los clientes.

Ofrecen la mejor respuesta a la interaccin, una interfaz

ms potente y mejor

experiencia de usuario.

Desplie