- Capa del Modelo de Dominio -

Transcripción

1 Presentación Global Guía Arquitectura Microsoft.NET 4.0 Patrones y Mejores prácticas - Capa del Modelo de Dominio - Pierre Milet Senior Consultant Microsoft - Services Architecture

2 Agenda Principios y Patrones de Diseño Filosofía Domain Driven Design (DDD) Patrones DDD. Repaso Code First

3 Principios de Diseño Principios Comunes Keep It Simple Stupid ( KISS ) Don t Repeat Yourself (DRY) Tell Don t Ask You Ain t Gonna Need It (YAGNI) Separation of Concerns (SoC) Principios S.O.L.I.D Single Responsability Principle (SRP) Open-Closed Principle (OCP) Liskov Substitution Principle (LSP) Interface Segregation Principle (ISP) Dependency Inversion Principle (DIP) Dependency Injection (DI) Inversion of Control (IoC)

4 Fowler s Enterprise Patterns Domain Logic Patterns: Transaction Script Active Record Domain Model ORM Unit of Work Repository Data Mapper Identity Map Lazy Loading Query Object

5 Transaction Script vs Domain Model

6 Otras prácticas de diseño Test Driven Design ( TDD ) Domain Driven Design (DDD) Behavior Driven Design (BDD)

7 Centrémonos en el Dominio - Es el corazón de la aplicación. - Contiene lógica de negocio pura. - Debe estar libre de «contaminaciones» de las otras capas. - Independencia de la BD y tecnologías de acceso a datos (ADO.NET, ORMs, etc.) - Ciclos de desarrollo rápidos, continuos y de calidad gracias a las pruebas con foco en el negocio.

8 Arquitectura N-Capas Orientada al Dominio (Versión Completa) Capas Infraestructura Transversal Cliente Rico / RIA Cliente Servidor Web Vistas UI Vistas UI Cache Operaciones (Logging, Monitorización, etc.) Seguridad Controladores Capa de Servicios Distribuidos (Web-Services) Capa de Aplicación Servicios de Aplicación Agentes de Servicios Capa del Dominio Entidades del Dominio Workflows Servicios del Dominio Bases (Layer Supertype) Controladores Capa de Infraestructura de Persistencia de Datos Adaptadores (DTO Adapters...) Especificaciones de Consultas Contratos Repositorios Presentación Repositorios (Implementación) Persistencia (ORMs: EF, NHibernate) Bases (Layer Supertype) Modelo de Datos Agentes de Servicios Servidor de Aplicaciones Architecture Fuentes Datos Servicios Externos

9 Domain Driven Design (DDD) El diseño de dominios complejos requiere de un Modelo. Principal causa de fracaso de proyectos SW: requerimientos incompletos y falta de involucración del usuario final. Foco en el dominio de negocio exclusivamente. Independencia de la tecnología y de la metodología. Favorecer la comunicación inequívoca entre los expertos del dominio y el equipo de desarrollo gracias al Lenguaje Ubicuo. Se basa en un conjunto de Principios y Patrones utilizados a lo largo de todo el ciclo de vida de la solución.

10 DDD: Domain Driven Design Proceso y Ciclo de Vida del Proyecto - Ciclo de Vida del proyecto - Relación del equipo desarrollo, expertos negocio del cliente, etc. - Lenguaje ubicuo 80% Arquitectura 20% Architecture (*) En esta Arquitectura solo nos centramos en este 20%

11 DDD: EL Modelo Un sistema de abstracciones que describe ciertos aspectos de un dominio (de forma destilada) y que se puede utilizar para resolver problemas relacionados con dicho dominio. Mismo dominio diferentes modelos

12 DDD: Lenguaje Ubicuo Problema: Los expertos utilizan su jerga y los desarrolladores la suya para expresar el dominio en términos de diseño: Las discusiones (con los expertos), el diseño y el código están desconectados. Se requiere Traducir y el conocimiento se vuelve anémico. Solución: Utilizar el modelo cómo columna vertebral para construir un lenguaje común utilizado en las discusiones, el diseño y el código: Refinar e enriquecer constantemente el lenguaje. Refactorizar el diseño y el código cada vez que cambia el lenguaje. Los expertos velan por la adecuación del lenguaje. Los desarrolladores estar atentos a las ambigüedades que puedan surgir en el diseño.

13 Modelo Data Centric Diferencias en el lenguaje Modelo DDD

14 DDD: Ventajas e Inconvenientes Ventajas: Permite un nivel de abstracción suficiente para abarcar problemas de dominio grandes y complejos. Escala a dominios muy grandes Lenguaje común entre desarrollo y negocio ( Ubiquitous Language) Una vez dominado es una herramienta muy poderosa. Inconvenientes: El mapeo de entidades a BBDD relacionales es laborioso y toma tiempo ( a menos que tengamos una herramienta ORM cómo EF). Requiere esfuerzo para entender, experiencia para dominar.

15 Patrones de Diseño en DDD

16 Patrón Arquitectura N-Layer Architecture

17 Dependencias en las Arquitecturas N-Capas DDD Capa de Dominio El Dominio es el Corazón Mayoría de Dependencias a través de ABSTRACCIONES/INTERFACES (Idealmente con IoC e Inyección Depend.) IMPLEMENTACIONES SUSTITUIBLES

18 Architecture Patrón ENTITY

19 Clases Entidad situadas en Capa Dominio - Las Clases Entidad son del Dominio - Puedo querer sustituir el acceso a datos sin que afecte a mis clases entidad del Dominio - Mover Plantillas T4 de Entidades POCO ó STE a la Capa de Dominio Capa de Servicios Distribuidos (Web-Services) Capa de Aplicación Servicios de Aplicación Workflows Adaptadores (DTO Adapters...) Capa del Dominio Entidades del Dominio Servicios del Dominio Bases (Layer Supertype) Especificaciones de Consultas Contratos Repositorios Capa de Infraestructura de Persistencia de Datos Repositorios (Implementación) Persistencia (ORMs: EF, NHibernate) Bases (Layer Supertype) Modelo de Datos Agentes de Servicios Servidor de Aplicaciones

20 Entidad (Patrón Entity) - Objeto que tiene una Identidad propia - Se caracteriza por si misma (Identidad) no por sus atributos. - Atributos mutables/cambiantes, pero siempre la misma Identidad - Trazabilidad continuidad en el tiempo (sufren cambios de estado). - Lógica propia en la clase entidad - No caer en Anemic Domain Model (MFowler) - Clases-Entidad situadas en la Capa de Dominio - Son Entidades de Negocio/Dominio Ej: Persona, Cliente, Pedido, Transacción

21 [ LABS ] -Implementación del patrón Entidad. Architecture

22 Architecture Value-Object pattern

23 Objeto Valor No tienen identidad. Lo determina el modelo. Describen cosas. Son intercambiables, transitorios. Deben ser inmutables. Pueden referenciar entidades. Útiles para optimizar acceso a BBDD (desnormalización) Ejemplo: Color Dirección Postal Las características de un modelo coche. Una ruta entre 2 ciudades

24 ENTIDADES vs. OBJETO-VALOR Entidad Persona Entidad Persona OBJETO- VALOR Direccion

25 [ LABS ] -Implementación del patrón Objeto Valor. - Uso de Complex Types de EF. Architecture

26 Architecture Service pattern

27 Servicios Representan actividades o acciones ( no objetos ) del dominio ( UL ). Suelen coordinar el trabajo de varias objetos del dominio. Ofrecida a través de un interfaz. No guardan estado. No confundir con servicios de aplicación (Servicio Web) o infraestructura ( , exporting data to excel) Ejemplo: Servicio de transferencia de fondos entre 2 cuentas bancarias.

28 Ejemplo: Separación en capas Aplicación: Funds Transfer App Service - Digiere los datos de entrada (XML) - Envía un mensaje al servicio de dominio. - Escucha confirmaciones. - Decide enviar notificaciones a través de los servicios de infraestructura Dominio: Funds Transfer Domain Service - Interactúa con objeto cuenta y contrato. - Devuelve confirmación de resultados (Transferencia permitida o no) Infraestructura: Send Notification Service Envía s, cartas y otras comunicaciones, invocadas por la applicacción

29 [ LABS ] - Implementación del patrón Servicio de Dominio. Architecture

30 Architecture Aggregate pattern

31 Agregados Conjunto de objetos relacionados tratados cómo una unidad. Entidad raíz : responsable de verificar reglas de consistencia (invariantes). Única entidad referenciable desde el exterior. ( incluido repositorios ) El resto de entidades tienen identidad local. Los objetos dentro del agregado pueden mantener referencias a otras entidades raíz. Al borrar una entidad raíz borramos en cascada el resto de objetos del agregado.

32 [ LABS ] - Implementación del patrón agregado. Architecture

33 Architecture Factory pattern

34 Factorías No intervienen en el modelo pero son parte de la capa de dominio. Responsables de crear objetos complejos o agregados. Responsable de verificar reglas de consistencia (invariantes).

35 Architecture Repository pattern

36 Repositorios Responsables de la persistencia de las entidades raíz. Su Interfaz utiliza términos del dominio (ubiquitous language). El interfaz pertenece a la capa de dominio, su implementación a la capa de infraestructura. Crea la ilusión de que los objetos están en memoria. Implementa Unit of Work para coordinar la escritura a la BBDD y resolver conflictos de concurrencia ( mantiene consistencia ) Puede ser considerado cómo un tipo especial de factoría. Ejemplo: CustomerRepository ProductCatalog

37 [ LABS ] - Implementación de Factorías e interfaces de repositorio. Architecture

38 Módulos Permiten dividir un dominio complejo en módulos más simples (conceptos de alto nivel extraídos del UL) Nos abstraen del resto del modelo. 2 vistas: La interna muestra los detalles La externa muestra las relaciones con otros módulos. Agrupan conceptos del dominio relacionados (sinergia). Bajo acoplamiento, alta cohesión Agrupar por conceptos del dominio no de la infraestructura. Ejemplo: Billing Customer Shipping

39 Contextos Bounded Contexts (BC): Delimitación del modelo. Debemos crear fronteras explicitas a nivel de código, equipo etc ( context map) Anticorruption Layer Capa que aísla 2 BC. Ofrece mecanismos de traducción entre ambos modelos. Shared Kernel: Subconjunto del sistema compartido por varios BC.

40 [ Demo ] - Bounded Contexts. Architecture

41 Entity Framework Code-First (CTP5) Desarrollar sin tener que abrir el diseñador para definir el archivo XML de mapeo. Definir modelos de objetos escribiendo clases POCO Usar una aproximación de convención sobre configuración Sobreescribir opcionalmente esa convención de persistencia y usar una API fluida. Architecture

42 [ Demo ] - Entity Framework Code First con CTP5

43 El Dominio «Es el corazón de la aplicación».

44 Contacto Pierre Milet Senior Consultant Microsoft Services * pierreml@microsoft.com