Guía arquitectura n capas orientada al dominio - microsoft architecture (1a edicion noviembre 2010)
Transcript of Guía arquitectura n capas orientada al dominio - microsoft architecture (1a edicion noviembre 2010)
-
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 ([email protected]), 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