Este documento describe el diseño orientado a dominio (DDD), un estilo arquitectónico que separa la aplicación en capas lógicas centradas en el dominio del negocio. Explica que la capa del dominio contiene la lógica y reglas del negocio, mientras que las capas de interfaz de usuario, aplicación e infraestructura se encargan de la presentación, coordinación y almacenamiento respectivamente. También discute patrones como entidades, objetos de valor, repositorios y servicios que ayudan a modelar el dominio

1. Domain-Driven Design(DDD)
twitter: @trukuxzo

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

3. Capas vs Niveles (Layers vs. Tiers)
Es la separación física en
Es la forma de organizar el diferentes proyectos
código lógicamente y no físicamente

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

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

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

7. Diagrama de Evans

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

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

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

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

12. Diagrama Sugerida
User Interface
Views Controllers Services
Application
Application
Web Services
Services
Domain
Domain
Domain Entities Repositories
Services
Infraestructure
Repositories
Utilities
Implementation

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

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

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

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

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

18. Ejemplos
.Net
http://code.google.com/p/ndddsample/
Java
http://dddsample.sourceforge.net/

19. Fin