+ All Categories
Home > Documents > DDD - (Spanish)

DDD - (Spanish)

Date post: 07-Nov-2014
Category:
Upload: fort-fernandez-encalada
View: 1,589 times
Download: 0 times
Share this document with a friend
Description:
Domain-Driven Design (DDD)
Popular Tags:
19
Domain-Driven Design(DDD) twitter: @trukuxzo
Transcript
Page 1: DDD - (Spanish)

Domain-Driven Design(DDD)

twitter: @trukuxzo

Page 2: DDD - (Spanish)

Domain-Driven Design(DDD)

Es una forma de diseñar el software centrándonos en lo que el cliente nos pide. El software que hacemos tiene como objetivo resolver un problema de nuestro cliente.

DDD es un estilo arquitectural. Se parece bastante a un estilo en N-Layer en tanto que los dos estilos separan las responsabilidades de la aplicación, pero la forma de hacerlo es ligeramente distinta.

Page 3: DDD - (Spanish)

Capas vs Niveles (Layers vs. Tiers)

Es la forma de organizar el código lógicamente y no físicamente

Es la separación física en diferentes proyectos

Page 4: DDD - (Spanish)

Consideraciones

Nuestro lenguaje debe ser el mismo que el del usuario.

No deberíamos usar otros términos.

Tenemos que dejar de hablar de formas de implementación (ej.: tablas) y pasar a hablar en términos menos técnicos, que estén más cerca del lenguaje del usuario y del negocio.

Page 5: DDD - (Spanish)

Ejemplos Escritos

• “Si le damos al servicio de ruteo un origen, un destino, una fecha de llegada, puede buscar las paradas a hacer… Y guardarlas en la base de datos” (vago y técnico)

• “El origen, destino y otros datos… se los damos al servicio de ruteo y nos devuelve un itinerario que tiene todo lo que necesitamos”(mejor, pero muchas palabras)

• “Un servicio de ruteo encuentra un itinerario que satisface una especificación de ruta” (conciso)

En este proceso de conversación con el usuario, se van descubriendo sustantivos que representan conceptos del dominio.

Page 6: DDD - (Spanish)

Evans Escribe

En una aplicación de carga y envío de mercadería, para simplemente listar y seleccionar el destino de la carga de una lista de ciudades, debe haber código que (1) dibuje un control en la pantalla, (2) consulte una base de datos para obtener las posibles ciudades, (3) interprete el ingreso de usuario y lo valide, (4) asocie la ciudad seleccionada con la carga, y (5) confirme el cambio en la base de datos. Todo este código es parte del mismo programa, pero sólo una pequeña parte está relacionado con el negocio de envío de cargas.

Page 7: DDD - (Spanish)

Diagrama de Evans

Page 8: DDD - (Spanish)

User Interface

La más fácil de entender, esta capa es la responsable de mostrar información al usuario, y aceptar nuevos datos. Puede ser implementada para web, escritorio gráfico, o cualquier otra tecnología de presentación, presente o futura.

Se pueden hacer las presentaciones en entornos tales como:– Web: ASP.NET, ASP.NET MVC– WinForms– WPF– Silverlight

Page 9: DDD - (Spanish)

Application

Define los trabajos que el software debe realizar y dirige los objetos del dominio para que trabajen en cada problema.

En general, es delgada, no contiene reglas de negocio o conocimiento, sino coordina tareas y delega el trabajo a colaboraciones de objetos del dominio.

No mantiene estado que refleje la situación del negocio, pero puede mantener estado sobre el progreso de una tarea del usuario o programa

Page 10: DDD - (Spanish)

Domain

En esta capa reside el corazón del software, según Evans. Las reglas y lógica de negocio residen en esta capa. El estado de entidades de negocio y su conducta es definida y usada aquí.

La comunicación con otros sistemas, detalles de persistencia, son delegados en la capa de Infraestructura mediante interfaces.

Evans sugiere que se pueden ayudar con los patrones que él usa en esta capa, como:

– Entities– Value Objects– Repositories – Services y – Factories.

Page 11: DDD - (Spanish)

Infraestructure

Esta capa es la responsable de implementar el mecanismo de persistencia del modelo de dominio y de proporcionar la implementación de todas las operaciones de comunicación.

La capa de infraestructura implementa las interfaces de los repositorios definidas en la capa de dominio para el mecanismo escogido (ficheros, base de datos, etc). y todas aquellas operaciones de comunicación con el mundo exterior que necesite el dominio (Emailer,Logger, etc.)

El mecanismo escogido para la persistencia debe ser transparente a la capa de dominio.

Page 12: DDD - (Spanish)

Diagrama SugeridaUser Interface

Application

Domain

Infraestructure

Views Controllers Services

Application Services

Web Services

Domain Services

Domain Entities

Repositories

UtilitiesRepositories

Implementation

Page 13: DDD - (Spanish)

Evans Propone

El propone que el modelo de dominio resida en una capa, la Capa de Dominio. De esta forma, el modelo de dominio es protegido de los detalles técnicos, como la implementación de la persistencia, y los detalles de presentación.

Me gusta decir que el dominio es un organismo, que recibe estímulos, acciones desde el exterior, y reacciona a esos comandos.

El dominio debería ejecutarse sin conocimiento detallado del resto de la aplicación, serialización entre capas físicas, detalles de presentación, y acceso a base de datos, deben estar claramente separados de la implementación del dominio.

Page 14: DDD - (Spanish)

Patrones Auxiliares - Entity

• Tienen continuidad (viven a lo largo de la vida del sistema)

• Tienen identidad

• Pueden cambiar los valores, pero sigue siendo el mismo proveedor

Page 15: DDD - (Spanish)

Patrones Auxiliares – Value Objects

• Los Value Objects se utilizan para representar conceptos importantes en nuestro dominio, pero su propósito es muy distinto al de las entidades

• El objetivo de los Value Objects es describir un concepto importante para nuestro dominio

• No son entidades por que no tienen una clave.

Page 16: DDD - (Spanish)

Patrones Auxiliares – Repository

• Se necesitan recuperar objetos, en general Entities, una entity se puede alcanzar desde otra

• En la capa de dominio definimos las interfaces que nuestro nivel de aplicación va a utilizar para para instanciar entidades de nuestro dominio pero no su implementación, esta se delega en la capa de infraestructura.

• No se accede a la base de datos directamente

Page 17: DDD - (Spanish)

Patrones Auxiliares – Services

• Frecuentemente en el dominio aparecen operaciones que no encajen bien dentro de ninguna entidad ya sea por que la operación tenga entidad por sí misma o por que la operación involucre a múltiples tipos de entidades.

• También pueden ser operaciones que pueden cambiar según el caso (ej.: algoritmos de cálculo de descuento, etc.)

• Los servicios de dominio solo deben ser utilizados para orquestar las operaciones entre entidades y no deben jamás tener estado interno.

Page 18: DDD - (Spanish)

Ejemplos

.Net

http://code.google.com/p/ndddsample/

Java

http://dddsample.sourceforge.net/

Page 19: DDD - (Spanish)

Fin


Recommended