CAPA DE MODELO DE DOMINIO

INTEGRANTES: Alvares Mendoza, Jeam Pierre Ganoza Quispe, Anthony Guerrero Bello Harold Ibaez Valdiviezo, Miguelangel Iglesias Morales Jhonatan Moreno Nuez Jimmy

EL DOMINIO
Es responsable de representar conceptos de negocio, informacin sobre la situacin de los procesos de negocio e implementacin de las reglas del dominio

Esta capa, Modelo del Dominio, es el corazn del software.

SE DIFERENCIA MS POR:
Separar muy claramente el comportamiento de las reglas del dominio (reglas de negocio que son responsabilidad del modelo del dominio) de los detalles de implementacin de infraestructura (acceso a datos y repositorios concretos ligados a una tecnologa especfica como pueden ser ORMs)

Todo esto para incrementar drsticamente la mantenibilidad de nuestro sistema

ARQUITECTURA Y DISEO LGICO DE LA CAPA DE DOMINIO

SERVICIO DEL MODELO DE DOMINIO(JIMMY)

PATRN ESPECIFICACIN
Separar la sentencia de qu tipo de objetos deben ser seleccionados en una consulta del propio objeto que realiza la seleccin.

El objeto 'Especificacin' tendr una responsabilidad clara y limitada que deber estar separada y desacoplada del objeto de Dominio que lo usa.

En donde los usuarios tengan la libertad de realizar consultas abiertas y puedan ser guardas para un futuro. Como por ejemplo el usuario desea ver artculos de mas de 500 soles y pueda guardar esa consulta para ser revisada en un futuro.

PATRN SUBSUNCIN
Necesitamos seleccionar un conjunto de objetos basados en ciertos criterios y refrescar los resultados en la aplicacin en ciertos intervalos de tiempo.

Prueba la especificacin contra un objeto candidato para ver si ese objeto satisface todos los requerimientos expresados en la especificacin.

La 'Subsuncin' permite comparar especificaciones para ver si satisfaciendo una especificacin eso implica la satisfaccin de otra segunda especificacin.

CONSIDERACIONES DE DISEO DE LA CAPA DE DOMINIO

Minimizar la complejidad separando las diferentes tareas en diferentes reas de preocupacin y responsabilidad

Definir diferentes tipos de componentes del Dominio

Identificar las responsabilidades de las reglas del dominio.

Disear con alta cohesin.

No se deben mezclar diferentes tipos de componentes en las capas del dominio.

VENTAJAS DE ENTIDADES POCO E IPOCO (JHONATAN)

Independencia de las entidades con respecto a libreras de tecnologas

concretas.
Son clases relativamente ligeras que ofrecen un buen rendimiento. Son la opcin ms adecuada para Arquitecturas N-Layer DDD.

LGICA DEL DOMINIO EN LAS CLASES DE ENTIDADES

Si nuestra aplicacin se trata de una aplicacin o servicio con una fuerte orientacin SOA, en los servicios distribuidos se usarn solo DTOs gestionando nosotros mismos casusticas de concurrencia (Optimistic Concurrency gestionado por nosotros, etc.) y simplificando las entidades. En esos casos se recomienda el uso de entidades del dominio POCO, generadas por EF o por nosotros mismos. Las Entidades POCO ofrecen unas entidades muy simplificadas aunque nos ocasionar el tener que realizar un esfuerzo bastante mayor en la programacin/implementacin de nuestro sistema

CUNDO UTILIZAR ENTIDADES POCO?

En DDD es fundamental situar la lgica relativa a las operaciones internas de una entidad dentro de la clase de la propia entidad. As pues, deberemos aadir a cada clase entidad la lgica de negocio/dominio relativa a la parte interna de datos de cada entidad.

SITUACIN DE CONTRATOS/INTERFACES DE REPOSITORIOS EN CAPA DE DOMINIO

Son precisamente los interfaces de los repositorios lo nico que se conocer desde la capa de Dominio sobre los repositorios, y la propia instanciacin de las clases Repository ser realizada por el contenedor IoC elegido.

IMPLEMENTACIN DE SERVICIOS DEL DOMINIO

Un SERVICIO es una operacin o conjunto de operaciones ofrecidas como un interfaz que simplemente est disponible en el modelo. Las clases de SERVICIOS deben encapsular y aislar a la capa de infraestructura de persistencia de datos

SERVICIOS DEL DOMINIO COMO COORDINADORES DE PROCESOS DE NEGOCIO

En los mtodos de los Servicios del Dominio simplemente debemos interactuar con la lgica ofrecida por las entidades que entran en juego. En el ejemplo anterior llamamos a mtodos (ChargeMoney(), CreditMoney(), etc.) que pertenecen a las propias entidades

USO DEL PATRN SPECIFICATION

El uso del patrn specification se realizar normalmente desde la capa de aplicacin donde definimos las consultas lgicas que se quieren realizar, pero lo tendremos desacoplado con respecto a la implementacin real de dichas consultas lgicas que estar en la capa de infraestructura de persistencia y acceso a datos.