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.0Autores 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.0No 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

AgradecimientosCsar 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

ContenidoAGRADECIMIENTOS ........................................................................................... III CONTENIDO ........................................................................................................ IV PRLOGOS......................................................................................................... XIII ARQUITECTURA MARCO .NET MICROSOFT IBRICA ............................ XIX 1.- Introduccin ............................................................................................................................... xix 1.1.- Audiencia del documento ......................................................................................................... xix 1.2.- Objetivos de la Arquitectura Marco .NET ........................................................................ xix 1.3.- Niveles de la documentacin de la Arquitectura marco .NET .................................... xx 1.4.- Aplicacin Ejemplo en CODEPLEX ...................................................................................... xxi FUNDAMENTOS DE ARQUITECTURA DE APLICACIONES ......................... 1 EL PROCESO DE DISEO DE LA ARQUITECTURA ........................................ 7 1.2.3.4.5.6.Identificar los objetivos de la iteracin .................................................................................. 9 Seleccionar los casos de uso arquitecturalmente importantes ....................................... 9 Realizar un esquema del sistema ........................................................................................... 10 Identificar los principales riesgos y definir una solucin .................................................. 15 Crear Arquitecturas Candidatas ............................................................................................ 16 aspectos de domain driven design ....................................................................................... 18 6.1.- El lenguaje ubicuo .......................................................................................................................... 19 6.2.- Prcticas que ayudan a conseguir un buen modelo de dominio. ................................ 20 6.2.1.- Behavior Driven Development (BDD)............................................................................... 20 6.2.2.- Test Driven Development (TDD)........................................................................................ 20

ARQUITECTURA MARCO N-CAPAS ............................................................... 21 1.- Arquitectura de Aplicaciones en N-Capas.......................................................................... 21 1.1.- Capas vs. Niveles (Layers vs. Tiers) ....................................................................................... 21 1.2.- Capas.................................................................................................................................................. 22 1.3.- Principios Base de Diseo a seguir ...................................................................................... 27 1.3.1.- Principios de Diseo SOLID ................................................................................................. 27 1.3.2.- Otros Principios clave de Diseo.......................................................................................... 28 1.4.- Orientacin a tendencias de Arquitectura DDD (Domain Driven Design) ........ 29 1.5.- DDDD (Distributed Domain Driven Design) ................................................................. 32 2.- Arquitectura Marco N-Capas con Orientacin al Dominio .................................................. 32

v

2.1.- Capas de Presentacin, Aplicacin, Dominio e Infraestructura .................................. 33 2.2.- Arquitectura marco N-Capas con Orientacin al Dominio......................................... 34 2.3.- Desacoplamiento entre componentes .................................................................................. 50 2.4.- Inyeccin de dependencias e Inversin de control .......................................................... 53 2.5.- Mdulos ............................................................................................................................................ 58 2.6.- Subdivisin de modelos y contextos de trabajo ................................................................ 61 2.7.- Bounded Contexts........................................................................................................................ 62 2.8.- Relaciones entre contextos....................................................................................................... 63 2.8.1.- Shared Kernel................................................................................................................................. 63 2.8.2.- Customer/Supplier ....................................................................................................................... 63 2.8.3.- Conformista .................................................................................................................................... 64 2.8.4.- Anti-corruption Layer................................................................................................................. 64 2.8.5.- Separate ways ................................................................................................................................. 65 2.8.6.- Open Host....................................................................................................................................... 65 2.9.- Implementacin de bounded contexts en .NET ............................................................... 66 2.9.1.- Cmo partir un modelo de Entity Framework? ......................................................... 67 2.9.2.- Relacin entre bounded contexts y ensamblados ....................................................... 68 2.10.- Visin de tecnologas en Arquitectura N-Layer ............................................................... 69 2.11.- Implementacin de Estructura de Capas en Visual Studio 2010 ................................. 69 2.12.- Aplicacin ejemplo N-Layer DDD con .NET 4.0 ............................................................. 70 2.13.- Diseo de la solucin de Visual Studio ................................................................................. 71 2.14.- Arquitectura de la Aplicacin con Diagrama Layer de VS.2010 ................................ 79 2.15.- Implementacin de Inyeccin de Dependencias e IoC con UNITY ........................ 80 2.15.1.- Introduccin a Unity.................................................................................................................... 82 2.15.2.- Escenarios usuales con Unity .................................................................................................. 83 2.15.3.- Patrones Principales..................................................................................................................... 84 2.15.4.- Mtodos principales..................................................................................................................... 84 2.15.5.- Registro Configurado de tipos en Contenedor ............................................................. 85 2.15.6.- Inyeccin de dependencias en el constructor ................................................................. 85 2.15.7.- Inyeccin de Propiedades (Property Setter).................................................................... 88 2.15.8.- Resumen de caractersticas a destacar de Unity ............................................................ 89 2.15.9.- Cundo utilizar Unity .................................................................................................................. 89 3.- Orientacin a Arquitectura EDA (Event Driven Architecture) .................................... 90 4.- Acceso Dual a Fuentes de Datos ......................................................................................... 92 5.- Nveles Fsicos en despliegue (Tiers).................................................................................... 94 CAPA DE INFRAESTRUCTURA DE PERSISTENCIA DE DATOS................. 99 1.- Capa de Infraestructura de Persistencia de Datos ........................................................... 99 2.- Arquitectura y Diseo lgico de la Capa de Persistencia de Datos 1 ....................... 100 2.1.- Elementos de la Capa de Persistencia y Acceso a Datos............................................ 101 2.1.1.- Repositorios (Repository pattern) .....................................................................................101 2.1.2.- Modelo de Datos........................................................................................................................105 2.1.3.- Tecnologa de Persistencia (O/RM, etc.)..........................................................................106 2.1.4.- Agentes de Servicios Distribuidos externos ..................................................................106 2.2.- Otros patrones de acceso a datos ...................................................................................... 106 2.2.1.- Active Record ..............................................................................................................................107

vi

2.2.2.- Table Data Gateway..................................................................................................................107 2.2.3.- Data Mapper .................................................................................................................................108 2.2.4.- Lista de patrones para las capas de Persistencia de Datos ......................................108 3.- Pruebas en la capa de Infraestructura de Persistencia de Datos................................. 109 4.- Consideraciones generales de diseo del acceso a datos ............................................. 112 4.1.- Referencias Generales .............................................................................................................. 115 5.- Implementacin en .NET de la Capa de Persistencia de Datos ................................ 116 5.1.- Opciones de tecnologa para la Capa de Persistencia de Datos .............................. 117 5.2.- Seleccin de Tecnologa de Acceso a Datos ................................................................... 117 5.2.1.- Otras consideraciones tecnolgicas .................................................................................118 5.2.2.- Cmo obtener y persistir objetos desde el almacn de datos ............................120 5.3.- Posibilidades de Entity Framework en la Capa de Persistencia ................................ 121 5.3.1.- Qu nos aporta Entity Framework 4.0? .........................................................................121 5.4.- Creacin del Modelo de Datos Entidad-Relacin de Entity-Framework ............. 122 5.5.- Plantillas T4 de generacin de entidades POCO/Self-Tracking................................ 126 5.6.- Tipos de datos Entidades Self-Tracking ........................................................................... 129 5.7.- Importancia de situar las Entidades en la Capa del Dominio .................................... 130 5.7.1.- Separacin del Core de plantillas T4 STE .....................................................................134 5.8.- Plantillas T4 de Persistencia de Datos y conexin a las fuentes de datos ............ 135 5.9.- Implementacin de Repositorios con Entity Framework y Linq to Entities ........ 135 5.10.- Implementacin de Patrn Repositorio............................................................................. 136 5.10.1.- Clase Base para los Repositories (Patrn Layer Supertype) ................................138 5.10.2.- Uso de Generics en implementacin de clase base Repository .........................139 5.10.3.- Interfaces de Repositorios e importancia en el desacoplamiento entre componentes de capas .............................................................................................................................144 5.11.- Implementacin de Pruebas Unitarias e Integracin de Repositorios ................... 146 5.12.- Conexiones a las fuentes de datos ...................................................................................... 151 5.12.1.- El Pool de Conexiones a fuentes de datos ...................................................................152 5.13.- Estrategias para gestin de errores originados en fuentes de datos ...................... 154 5.14.- Agentes de Servicios Externos (Opcional) ....................................................................... 155 5.15.- Referencias de tecnologas de acceso a datos ................................................................. 155 CAPA DE MODELO DE DOMINIO .................................................................. 157 1.- El Dominio................................................................................................................................. 157 2.- Arquitectura y Diseo lgico de la Capa de Dominio ................................................... 158 2.1.- Aplicacin ejemplo: Caractersticas de negocio del Modelo de Dominio ejemplo a Disear 159 2.2.- Elementos de la Capa de Dominio ...................................................................................... 161 2.2.1.- Entidades del Dominio .............................................................................................................161 2.2.2.- Patrn Objeto-Valor (Value-Object pattern) ..............................................................168 2.2.3.- Agregados (Patrn Aggregate) ...........................................................................................171 2.2.4.- Contratos/Interfaces de Repositorios dentro de la Capa de Dominio .............173 2.2.5.- SERVICIOS del Modelo de Dominio.................................................................................174 2.2.6.- Patrn ESPECIFICACION (SPECIFICATION) ............................................................180 2.3.- Consideraciones de Diseo de la Capa de Dominio ................................................... 185 2.4.- EDA y Eventos del Dominio para articular reglas de negocio .................................. 187 2.4.1.- Eventos del Dominio Explcitos ...........................................................................................188

2.4.2.- Testing y Pruebas Unitarias cuando utilizamos Eventos del Dominio................188 3.- Implementacin de la Capa de Dominio con .NET 4.0 ................................................. 188 3.1.- Implementacin de Entidades del Dominio...................................................................... 189 3.2.- Generacin de entidades POCO/IPOCO con plantillas T4 de EF ......................... 194 3.3.- Lgica del Dominio en las Clases de Entidades .............................................................. 195 3.4.- Situacin de Contratos/Interfaces de Repositorios en Capa de Dominio ........... 196 3.5.- Implementacin de Servicios del Dominio ....................................................................... 198 3.5.1.- SERVICIOS del Dominio como coordinadores de procesos de Negocio ......199 3.6.- Patrn ESPECIFICACION (SPECIFICATION pattern) .............................................. 201 3.6.1.- Uso del patrn SPECIFICATION .......................................................................................201 3.6.2.- Implementacin del patrn SPECIFICATION ..............................................................202 3.6.3.- Especificaciones compuestas por operadores AND y OR........................................205 3.7.- Implementacin de pruebas en la capa del dominio ..................................................... 207 CAPA DE APLICACIN .................................................................................... 211 1.- Capa de Aplicacion .................................................................................................................. 211 2.- Arquitectura y Diseo lgico de la Capa de Aplicacin ................................................ 212 2.1.- Proceso de diseo de capa de Aplicacin ......................................................................... 214 2.2.- La importancia del desacoplamiento de la Capa de Aplicacin con respecto a Infraestructura ......................................................................................................................................... 215 3.- Componentes de la Capa de Aplicacin ............................................................................ 215 3.1.- Servicios de Aplicacin ............................................................................................................. 215 3.2.- Desacoplamiento entre SERVICIOS de APLICACION y REPOSITORIOS ....... 219 3.2.1.- Patrn Unidad de Trabajo (UNIT OF WORK).........................................................220 3.2.2.- Servicios Workflows de Capa de Aplicacin (Opcional) .........................................222 3.3.- Errores y anti-patrones en la Capa de Aplicacin ......................................................... 224 3.4.- Aspectos de Diseo relacionados con la Capa de Aplicacin .................................. 226 3.4.1.- Autenticacin................................................................................................................................226 3.4.2.- Autorizacin..................................................................................................................................227 3.4.3.- Cache ...............................................................................................................................................228 3.4.4.- Gestin de Excepciones ..........................................................................................................229 3.4.5.- Logging, Auditora e Instrumentalizacin .........................................................................229 3.4.6.- Validaciones ...................................................................................................................................230 3.4.7.- Aspectos de despliegue de la Capa de Aplicacin .......................................................231 3.4.8.- Concurrencia y Transacciones .............................................................................................231 3.5.- Mapa de patrones posibles a implementar en la capa de Aplicacin ...................... 232 4.- Implementacin en .NET de Capa de Aplicacion ........................................................... 234 4.1.- Implementacin de Servicios de Capa de Aplicacin ................................................... 235 4.1.1.- Desacoplamiento e Inyeccin de Dependencias entre Servicios de Aplicacin y Repositorios mediante IoC de UNITY.............................................................................................237 4.2.- Implementacin de Transacciones y UoW en Servicios de Capa de Aplicacin245 4.2.1.- Transacciones en .NET ............................................................................................................245 4.2.2.- Implementacin de Transacciones en la Capa de Servicios del Dominio ........249 4.2.3.- Modelo de Concurrencia en actualizaciones y transacciones ................................250 4.2.4.- Tipos de Aislamiento de Transacciones...........................................................................252 4.3.- Implementacin de pruebas en la capa de Aplicacin .................................................. 257

viii

CAPA DE SERVICIOS DISTRIBUIDOS............................................................ 259 1.- Situacin en Arquitectura N-Capas .................................................................................... 259 2.- Arquitecturas Orientadas a Servicios y Arquitecturas en N-Capas (N-Layer) ....... 261 3.- Situacin de Arquitectura N-Layer con respecto a Aplicaciones aisladas y a Servicios SOA ................................................................................................................................. 262 4.- Qu es SOA? ........................................................................................................................... 263 5.- Pilares de SOA (Service Orientation Tenets) .................................................................. 264 6.- Arquitectura interna de los Servicios SOA ...................................................................... 268 7.- Pasos de Diseo de la Capa de Servicios .......................................................................... 269 8.- Tipos de Objetos de Datos a comunicar .......................................................................... 270 9.- Consumo de Servicios Distribuidos basado en Agentes ............................................... 274 10.- Interoperabilidad ................................................................................................................ 276 11.- Rendimiento .......................................................................................................................... 277 12.- Comunicacin Asncrona vs. Sncrona ............................................................................ 278 13.- REST vs. SOAP...................................................................................................................... 279 13.1.- Consideraciones de Diseo para SOAP ........................................................................... 282 13.2.- Consideraciones de Diseo para REST ............................................................................. 283 14.- Introduccin a SOAP y WS-* ........................................................................................... 284 15.- Especificaciones WS-* ......................................................................................................... 284 16.- Introduccin a REST ............................................................................................................ 288 16.1.- La URI en REST........................................................................................................................... 288 16.2.- Simplicidad..................................................................................................................................... 289 16.3.- URLs lgicas versus URLs fsicas .......................................................................................... 290 16.4.- Caractersticas base de Servicios Web REST .................................................................. 290 16.5.- Principios de Diseo de Servicios Web REST ................................................................ 291 17.- ODATA: Open Data Protocol ......................................................................................... 292 18.- Reglas globales de Diseo para sistemas y servicios SOA ....................................... 295 19.- Implementacin de la Capa de Servicios Distribuidos con WCF .NET 4.0 .......... 300 20.- Opciones tecnolgicas ........................................................................................................ 301 20.1.- Tecnologa WCF ........................................................................................................................ 301 20.2.- Tecnologa ASMX (Servicios Web ASP.NET)................................................................. 302 20.3.- Seleccin de tecnologa ............................................................................................................ 303 20.4.- Tipos de Despliegue de Servicios WCF........................................................................... 303 21.- Introduccin a WCF (Windows Communication Foundation) ............................... 307 21.1.- El ABC de Windows Communication Foundation ..................................................... 309 21.2.- Definicin e implementacin de un servicio WCF ....................................................... 312 21.3.- Hospedaje del servicio (Hosting) y configuracin (Bindings)..................................... 316 21.4.- Configuracin de un servicio WCF..................................................................................... 318 22.- Implementacin de Capa de Servicios WCF en Arquitectura N-Layer ................. 320 23.- Tipos de Objetos de Datos a Comunicar con Servicios WCF ................................ 322 24.- Cdigo de Servicio WCF publicando lgica de Aplicacin y Dominio .................. 325 24.1.- Desacoplamiento de objetos de capas internas de la Arquitectura, mediante UNITY 325 24.2.- Gestin de Excepciones en Servicios WCF..................................................................... 327 24.3.- Tipos de alojamiento de Servicios WCF y su implementacin ................................ 327 25.- Despliegue y Monitorizacin de Servicios WCF en Windows Server AppFabric 332

25.1.- Instalacin y configuracin de Windows Server AppFabric. ..................................... 333 25.2.- Despliegue de servicios WCF en Windows Server AppFabric................................ 336 25.2.1.- Identidad de acceso a B.D. SQL Server e Impersonacin de nuestra aplicacin WCF 338 25.3.- Monitorizacin de servicios WCF desde la consola de Windows Server AppFabric en IIS Manager. .................................................................................................................. 340 26.- Referencias Globales DE WCF y Servicios ................................................................... 343 CAPA DE PRESENTACIN .............................................................................. 345 1.- Situacin en Arquitectura N-Capas .................................................................................... 345 2.- Necesidades de invertir en la interfaz de usuario ........................................................... 346 3.- Necesidad de arquitecturas en la capa de presentacin ............................................... 348 3.1.- Acoplamiento entre capas ...................................................................................................... 348 3.2.- Bsqueda de rendimiento. ...................................................................................................... 349 3.3.- Pruebas unitarias ......................................................................................................................... 349 4.- Patrones de Arquitectura en la capa de Presentacin ................................................... 350 4.1.- Patrn MVC (Modelo Vista Controlador) ....................................................................... 350 4.2.- El modelo....................................................................................................................................... 352 4.3.- Las vistas ........................................................................................................................................ 352 4.4.- El controlador .............................................................................................................................. 353 4.5.- Patrn MVP (Modelo Vista Presentador) ......................................................................... 353 4.6.- Patrn MVVM (Model-View-ViewModel) ...................................................................... 355 4.7.- Visin global de MVVM en la arquitectura orientada a dominios............................ 356 4.8.- Patrones de diseo utilizados en MVVM ........................................................................... 357 4.8.1.- El patrn Comandos (Command) ......................................................................................357 4.8.2.- El patrn Observador (Observer)......................................................................................360 5.- Implementacin de Capa DE Presentacin ....................................................................... 362 5.1.- Arquetipos, Tecnologas UX y Patrones de Diseo relacionados .......................... 364 5.2.- Implementacin de Patrn MVVM con WPF 4.0........................................................... 366 5.2.1.- Justificacin de MVVM ..............................................................................................................367 5.2.2.- Diseo con patrn Model-View-ViewModel (MVVM) .............................................371 5.3.- Implementacin del patrn MVVM en Silverlight 4.0 .................................................. 377 5.3.1.- Modelo de programacin asncrona ..................................................................................378 5.3.2.- Modelo de validaciones ............................................................................................................380 5.4.- Beneficios y Consecuencias del uso de MVVM .............................................................. 381 6.- Validacin de datos en la interfaz (WPF) .......................................................................... 382 7.- Validacin de datos en la interfaz de Usuario (Silverlight) ............................................ 385 8.- Implementacin con asp.net MVC 2.0 ............................................................................... 387 8.1.- Fundamentos de ASP.NET MVC.......................................................................................... 388 8.2.- El pipeline de ASP.NET MVC ................................................................................................ 388 8.3.- Un ejemplo completo: Actualizacin de un cliente ....................................................... 390 8.4.- Otros aspectos de la aplicacin ............................................................................................ 393 CAPAS DE INFRAESTRUCTURA TRANSVERSAL ....................................... 395 1.- Capas de Infraestructura Transversal ................................................................................. 395 2.- Situacin de Infraestructura Transversal en la Arquitectura ........................................ 396

x

3.- Consideraciones Generales de Diseo .............................................................................. 396 4.- Aspectos Transversales.......................................................................................................... 398 4.1.- Seguridad en la aplicacin: Autenticacin y Autorizacin ........................................... 399 4.1.1.- Autenticacin................................................................................................................................399 4.1.2.- Autorizacin..................................................................................................................................400 4.1.3.- Arquitectura de Seguridad basada en Claims ..............................................................401 4.2.- Cache .............................................................................................................................................. 406 4.3.- Gestin de Configuracin ....................................................................................................... 408 4.4.- Gestin de Excepciones .......................................................................................................... 409 4.5.- Registro/Logging y Auditoras ................................................................................................ 410 4.6.- Instrumentalizacin .................................................................................................................... 410 4.7.- Gestin de Estados .................................................................................................................... 411 4.8.- Validacin....................................................................................................................................... 411 5.- Implementacin en .NET de Aspectos Transversales .................................................... 413 5.1.- Implementacin en .NET de Seguridad basada en Claims........................................ 413 5.1.1.- STS y ADFS 2.0............................................................................................................................413 5.1.2.- Pasos para implementar Orientacin a Claims con WIF .......................................416 5.1.3.- Beneficios de la Orientacin a Claims, WIF y ADFS 2.0 ........................................419 5.2.- Implementacin de Cache en plataforma .NET.............................................................. 419 5.2.1.- Implementacin de Cache-Servidor con Microsoft AppFabric-Cache .............419 5.2.2.- Implementacin de AppFabric-Cache en aplicacin ejemplo DDD NLayerApp 426 5.2.3.- Implementacin de Cache en Nivel Cliente de Aplicaciones N-Tier (RichClient y RIA) .................................................................................................................................................432 5.3.- Implementacin de Logging/Registro .................................................................................. 433 5.4.- Implementacin de Validacin ............................................................................................... 433 ARQUETIPOS DE APLICACIN ..................................................................... 435 1.2.3.4.5.6.7.8.Arquetipo Aplicacin Web ................................................................................................. 437 Arquetipo Aplicaciones RIA................................................................................................ 439 Arquetipo Aplicacin rica de escritorio (Rich Client) ................................................. 441 Arquetipo Servicio Distribuido - SOA ............................................................................... 443 Arquetipo Aplicaciones Mviles .......................................................................................... 446 Arquetipo Aplicaciones Cloud Computing .................................................................... 448 Arquetipo Aplicaciones OBA (Office Business Applications) ...................................... 452 Arquetipo Aplicacin de negocio basada en Sharepoint ............................................. 455

ARQUITECTURA Y PATRONES EN CLOUD-COMPUTING PAAS ........ 459 1.- Arquitectura de Aplicaciones en la nube........................................................................... 460 2.- Escenarios de Arquitectura en la nube .............................................................................. 463 3.- Escenario Bsico: Migracin directa de aplicacin On-Premise a la Nube ............... 463 3.1.- Arquitectura Lgica (Escenario Bsico) ............................................................................. 463 3.2.- Por qu hacer uso de Windows Azure?.......................................................................... 464 3.3.- Breve introduccin a la plataforma Windows Azure ................................................... 465 3.3.1.- Procesamiento en Windows Azure .................................................................................468 3.4.- Implementacin de escenario bsico en plataforma Windows Azure .................. 469

3.5.- Pasos para migrar Aplicacin ejemplo NLayerApp a Windows Azure (Escenario Bsico en la nube) .................................................................................................................................. 472 3.5.1.- Migracin de Base de Datos SQL Server ........................................................................473 3.5.2.- Cambio de cadena de conexin de ADO.NET / EF ..................................................483 3.5.3.- Migracin de proyectos en hosting de IIS a Azure......................................................484 3.5.4.- Despliegue en la nube de Windows Azure en Internet ...........................................491 3.5.5.- Gestin de imgenes en Web: Cambio de almacn local (disco) a Windows Azure Blobs ...................................................................................................................................................496 3.5.6.- Seguridad en Windows Azure..............................................................................................496 3.5.7.- Otros puntos a tener en cuenta al migrar aplicaciones a Windows Azure ....497 4.- Escenario Avanzado: Aplicacin Escalable en Cloud-Computing................................ 498 4.1.- Arquitectura Lgica (Escenario Avanzado en la nube) ............................................... 499 4.2.- Patrn CQRS (Command and Query Responsibility Segregation)......................... 499 4.2.1.- Por qu CQRS? .........................................................................................................................502 CONCLUSIONES ............................................................................................... 505

xii

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

xiii

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.

xiv

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.

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.

xvi

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

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

Arquitectura Marco .NET Microsoft Ibrica1.- INTRODUCCINMicrosoft 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.

1.1.- Audiencia del documentoEste documento est dirigido a las personas involucradas en todo el ciclo de vida de productos software o de aplicaciones corporativas desarrolladas a medida. Especialmente los siguientes perfiles: Arquitecto de Software Desarrollador

1.2.- Objetivos de la Arquitectura Marco .NETEste 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.

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.

1.3.- Niveles de la documentacin de la Arquitectura marco .NETLa 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:

xx

1.4.- Aplicacin Ejemplo en CODEPLEXEs 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.:

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.0Silverlight Lista de Clientes

xxii

Silverlight Transicin de Silverlight

Silverlight Vista de Cliente

Cliente WPF 4.0WPF Vista de Lista de Clientes

WPF Vista de Cliente

xxiv

WPF Transferencias Bancarias

Cliente ASP.NET MVCMVC Transferencias Bancarias

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:

xxvi

CAPTULO

1

Fundamentos de Arquitectura de AplicacionesEl 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 sistema1

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:


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.

CAPTULO

2

El proceso de Diseo de la Arquitectura

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


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

1.- IDENTIFICAR LOS OBJETIVOS DE LA ITERACINLos 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.

2.- SELECCIONAR LOS CASOS DE USO ARQUITECTURALMENTE IMPORTANTESEl 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.


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.

3.- REALIZAR UN ESQUEMA DEL SISTEMAUna 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:


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 Aplicaciones para dispositivos mviles

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

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

Despliegue complejo. Versionado complicado. Poca interoperabilidad.


Proporcionan una interaccin muy dinmica. Soportan escenarios desconectados o con conexin limitada. RIA (Rich Internet Applications) Proporcionan la misma potencia grfica que las aplicaciones de escritorio. Ofrecen soporte para visualizar contenido multimedia. Despliegue y distribucin simples. Algo ms pesadas que las aplicaciones web. Aprovechan peor los recursos que las aplicaciones de escritorio. Requieren tener instalado un plugin para funcionar. No tienen interfaz grfica. Necesitan conexin a internet.

Aplicaciones orientadas a servicios

Proporcionan una interfaz muy desacoplada entre cliente y servidor. Pueden ser consumidas por varias aplicaciones sin relacin. Son altamente interoperables

Aplicaciones web

Llegan a todo tipo de usuarios y tienen una interfaz de usuario estndar y multiplataforma. Son fciles de desplegar y de actualizar.

Dependen de la conectividad a red. No pueden ofrecer interfaces de usuario complejas.


Una vez que tenemos decidido el tipo de aplicacin que vamos a desarrollar, el siguiente paso es disear la arquitectura de la infraestructura, es decir, la topologa de despliegue. La topologa de despliegue depende directamente de las restricciones impuestas por el cliente, de las necesidades de seguridad del sistema y de la infraestructura disponible para desplegar el sistema. Definimos la arquitectura de la infraestructura en este punto, para tenerla en consideracin a la hora de disear la arquitectura lgica de nuestra aplicacin. Dado que las capas son ms maleables que los niveles, encajaremos las distintas capas lgicas dentro de los niveles del sistema. Generalizando existen dos posibilidades, despliegue distribuido y despliegue no distribuido. El despliegue no distribuido tiene la ventaja de ser ms simple y ms eficiente en las comunicaciones ya que las llamadas son locales. Por otra parte, de esta forma es ms difcil permitir que varias aplicaciones utilicen la misma lgica de negocio al mismo tiempo. Adems en este tipo de despliegue los recursos de la mquina son compartidos por todas las capas con lo que si una capa emplea ms recursos que las otras existir un cuello de botella. El despliegue distribuido permite separar las capas lgicas en distintos niveles fsicos. De esta forma el sistema puede aumentar su capacidad aadiendo servidores donde se necesiten y se puede balancear la carga para maximizar la eficiencia. Al mismo tiempo, al separar las capas en distintos niveles aprovechamos mejor los recursos, balanceando el nmero de equipos por nivel en funcin del consumo de las capas que se encuentran en l. El lado malo de las arquitecturas distribuidas es que la serializacin de la informacin y su envo por la red tienen un coste no despreciable. As mismo, los sistemas distribuidos son ms complejos y ms caros. Tras decidir qu tipo de aplicacin desarrollaremos y cul ser su topologa de despliegue llega el momento de disear la arquitectura lgica de la aplicacin. Para ello emplearemos en la medida de lo posible un conjunto de estilos arquitecturales conocidos. Los estilos arquitecturales son patrones de nivel de aplicacin que definen un aspecto del sistema que estamos diseando y representan una forma estndar de definir o implementar dicho aspecto. La diferencia entre un estilo arquitectural y un patrn de diseo es el nivel de abstraccin, es decir, un patrn de diseo da una especificacin concreta de cmo organizar las clases y la interaccin entre objetos, mientras que un estilo arquitectural da una serie de indicaciones sobre qu se debe y qu no se debe hacer en un determinado aspecto del sistema. Los estilos arquitecturales se pueden agrupar segn el aspecto que definen como muestra la siguiente tabla:Tabla 2.- Aspectos estilos estructurales

Aspecto Comunicaciones Despliegue Dominio Interaccin Estructura

Estilos arquitecturales SOA, Message Bus, Tuberas y filtros. Cliente/Servidor, 3-Niveles, N-Niveles. Modelo de dominio, Repositorio. Presentacin separada. Componentes, Orientada a objetos, Arquitectura en capas.


Como se desprende de la tabla, en una aplicacin usaremos varios estilos arquitecturales para dar forma al sistema. Por tanto, una aplicacin ser una combinacin de muchos de ellos y de soluciones propias. Ahora que ya hemos decidido el tipo de aplicacin, la infraestructura fsica y la estructura lgica, tenemos una buena idea del sistema que construiremos. El siguiente paso lgico es comenzar con la implementacin del diseo y para ello lo primero que tenemos que hacer es decidir qu tecnologas emplearemos. Los estilos arquitecturales que hemos usado para dar forma a nuestro sistema, el tipo de aplicacin a desarrollar y la infraestructura fsica determinarn en gran medida estas tecnologas. Por ejemplo, para hacer una aplicacin de escritorio escogeremos WPF o Silverlight 3, o si nuestra aplicacin expone su funcionalidad como servicios web, usaremos WCF. En resumen las preguntas que tenemos que responder son: Qu tecnologas ayudan a implementar los estilos arquitecturales seleccionados? Qu tecnologas ayudan a implementar el tipo de aplicacin seleccionada? Qu tecnologas ayudan a cumplir con los requisitos no funcionales especificados?

Lo ms importante es ser capaz al t

Guía Arquitectura N-Capas Orientada al Dominio - Microsoft Architecture (1a Edicion Noviembre 2010)

Documents

Transcript of Guía Arquitectura N-Capas Orientada al Dominio - Microsoft Architecture (1a Edicion Noviembre 2010)