VAN - Diciembre 19 de 2009 - Domain Driven Design

 

Formato

     Reunión virtual

 

Duración:

     Vídeo: 1:45 horas 

 

Ponente:

     Angel “Java” López

 

Síntesis:

 

Hacia el Dominio

El corazón del software

 

Estilos de Arquitectura

  • Foco en el dominio
    • Antes: Bases de Datos
    • Ahora: OOP
  • Foco en los casos de uso
  • Foco en diseño dirigido por el dominio
    • Se va construyendo sobre el modelo de dominio que se va descubriendo.

 

Dominio

  • Es el área donde el usuario aplica el programa que construimos
  • Hay dominios con objetos “reales"

    Si fuera una agencia marítima, tendría objetos como buques, contenedores, carga, etc.

  • Hay dominios con objetos “más intangibles”

    Un programa contable: dinero, documentos, transacciones

 

Modelo

  • Una de las palabras más “sobrecargadas”de significados distintos
  • Es una representación de algo
  • En esta charla, modelo es:
    • Parcial
    • Una abstracción
    • Una herramienta
  • Puede haber varios modelos en un sistema (de deployment, de aquitectura, etc.)
  • Es el mapa, no el territorio

 

Modelo de Dominio

  • Es una representación del dominio
  • Antes, teníamos modelos, pero muchas veces infectados de infraestructura y otros temas
  • Ahora, este modelo es sólo de dominio

 

Ideas de Eric Evans

  • Para crear valor para el usuario, los desarrolladores deben conocer sus actividades
  • Esas actividades son el dominio
  • Se va diseñando un modelo del dominio

    Una abstracción, aunque el dominio sean “cosas reales”

  • Se implemente “lo más parecido posible”

    No hay modelo de análisis vs modelo de implementación

  • El proceso:
    • Destila el conocimiento del dominio que tienen los usuarios
    • Es (puede ser) ágil

 

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.

 

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.

 

Lenguage Ubicuo

Es la intersección de 2 lenguajes: el técnico y el de negocio

 

Un poco de historia

  • Mucho de la historia de Microsoft fue data oriented (DAO, RDO, ADO, ADO.NET, DataBinding, etc.)
  • En el mundo de Java, modelo de dominio fue lo “habitual” (look ma, no recordset desconectados)

    Olvidarse de EJB (Enterprise JavaBeans)

  • Al parecer .NET, Microsoft se basa en lo que ya conocían los desarrolladores que ya usaban sus productos

 

Idealmente

Trabajar con objetos. Programar “como Smaltalk”

Ver Naked Objects

 

Temas a Resolver

  • Tenemos más que dominio
  • Interactuar con usuarios (a.k.a. mortales)
  • Interactuar con otros sistemas
  • Aplicaciones distribuidas
  • Concurrencia

    Consistencia usando transacciones

  • Persistencia

    Base de datos relacionales

  • Reificando el dominio

 

No siempre podemos tenerlo totalmente en memoria. Ver Prevayler (http://www.prevayler.org/)

 

Aislando el Dominio

• Es común desde la UI acceder directamente a objetos del dominio

• También se coloca la lógica en la UI

• Cambiar una regla de negocio, entonces, implica mirar en código desperdigado

• Solución: una arquitectura en capas

 

Capas

• Cada una se especializa en un aspecto particular del programa

• Esto agrega cohesión a cada objeto

• Conocemos qué colocar en cada capa

• Conocemos qué modificar ante un cambio

• Muchos cambios son concentrados

• Contra: mayor cantidad de clases, casos de uso “scattered”en varios artefactos, cada artefacto tiene responsabilidades de distintos casos de uso

 

Capa de Presentación

• Responsable de mostrar la información al usuario, e interpretar sus comandos

• El usuario externo puede ser en algunos casos otro sistema de computación

• Tipos de presentación

o Web: ASP.NET, ASP.NET MVC

o WinForms

o WPF

o Silverlight

 

Capa de Aplicación

  • Define los trabajos que el software debe realizar y dirije 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

 

Capa de dominio

  • Responsable de representar los conceptos del negocio, información sobre la situación del negocio y reglas del negocio
  • El estado del negocio es controlado y usado en esta capa
  • Se comunica con la infraestructura, pero en general mediante interfaces

 

Capa de infraestructura

  • Servicios que usan las otras capas
  • Servicios más comunes
    • Persistencia
    • Unit of work
    • Identity Map
    • Transacciones
    • Comunicaciones con otros sistemas

 

Patrones de Evans, sugeridos para implementar todas estas ideas

 

Entity

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

    Pueden cambiar los valores, pero sigue siendo el proveedor 17

 

Value Object

  • No tienen una identidad (conceptual)
  • Son su valor
  • Al cambiar de valor son otro objeto
  • Ejemplo clásico: Dirección, calle, nro, ciudad
  • Nota: una dirección puede ser una entidad, dependiendo del dominio

 

Repository

 

  • Se necesitan recuperar objetos, en general Entities
  • Una entity se puede alcanzar desde otra
  • Pero cómo conseguir una primer Entity, o un grupo de entities con una característica?
  • No accedemos a la base de datos directamente
  • Repository representa la colección de las entidades de algún tipo o característica

 

Aggregate

  • Hay entidades que refieran a otras entidades
  • Caso: Cliente -> Factura
  • Caso: Factura -> Renglones
  • Caso: Auto -> Ruedas
  • No todas son Aggregate
  • Según el dominio, los componentes no se acceden sino desde su Aggregate Root

 

Factory

  • Crear un Entity puede ser complejo
  • También crear todo un Aggregate
  • Para no exponer la estructura interna y proveer algún invariante, se usa Factory
  • Puede ser Factory Method
  • Puede ser una clase Factory

 

Service

  • Algunas operaciones no caen claramente en la responsabilidad de un objeto
  • También pueden ser operaciones que pueden cambiar según el caso (ej: algoritmos de cálculo de descuento, etc.)
  • Se escrube en Services (palabra con tantos significados…)

 

Command and Query Responsability Segregation (CQRS)

  • Basado en Command Query Separation (Bertrand Mayer)
  • Al interactuar con un objeto:
    • Métodos comando: actúan sobre el objeto
    • Métodos consulta: nos dan información sobre el objeto, pero no lo modifican
    • Caso “excepcional”: Stack.Pop()
  • A la Greg Young: Al impactar el dominio:
    • O le enviamos un Comando, para actual, modificarlo…
    • O le enviamos una Query, consulta, en general no al Dominio, sino a un sistema de Reporting
 

Enlaces:

 

Lecturas

 

Video

Si lo prefieren, pueden observar el vídeo en http://www.screencast.com/t/HCecrOxqd7 o descargar el archivo desde este enlace, el cual tiene un tamaño de 419.13 MB.

Unable to display content. Adobe Flash is required.