domain driven design - significado - Objetos y servicios de dominio

domain driven design pdf

Question

En esta pregunta, alguien responde "¡Nunca dejes que las implementaciones de objetos de dominio llamen a los servicios por sí mismos!". ¿Es esta afirmación una regla dura de DDD o depende de su propia aplicación y arquitectura?

Ejemplo de ejemplo:

Como ejemplo, supongamos que tenemos un objeto UserImage en nuestro modelo que se llena desde una imagen cargada por un usuario. Y luego supongamos que podemos enviar esta imagen a un servicio de terceros que pueda identificar huellas digitales y devolver un Guid si se encuentra una coincidencia.

public IThumbPrintService {
    Guid FindMatch(Bitmap image);
}

public class UserImage {
    public Bitmap Image {get; set;} 
    public Guid ThumbPrintId {get; set;}
    public bool FindThumbPrintMatch() {
       // Would you call the service from here?
       ThumbPrintId = _thumbPrintService.FindMatch(this.Image);
       return ! ThumbPrintId.CompareTo(Guid.Empty);
    }
}

public class RoboCopUserImageService : IUserImageService {
     // Or move the call to a service method 
     // since it depends on calling a separate service interface
     public bool FindThumbPrintMatch(UserImage userImage) {
        userImage.ThumbPrintId = _thumbPrintService.FindMatch(userImage.Image);
        return !userImage.ThumbPrintId.CompareTo(Guid.Empty);            
     }
}

¿Qué se evita u obtiene al no permitir que los objetos de dominio llamen a los servicios ellos mismos?

EDITAR: ¿Hay algún buen artículo en línea que debata sobre este tema específico?

Answer 1

Una desventaja que veo es que permitir que su objeto de dominio llame a servicios puede dificultar la serialización, o al menos causar algunos problemas después de serializarlo cuando alguien en el otro lado llama a su (s) método (s) de servicio.

Answer 2

Si permite que un Objeto de entidad llame a un servicio, está realizando dos roles Objeto de datos y Objeto de servicio. Generalmente, cada objeto debe tener responsabilidad, no solo en la implementación sino también en el uso.

En su caso, la humilde UserImage parece ser una imagen y un reconocedor de ThumbPrint.

Answer 3

Este es el acertijo de hoja de cálculo : ¿el teléfono marca el número de teléfono o el número de teléfono se marca solo en el teléfono ?

Puede que le parezca que Double Dispatch es una lectura interesante, aunque exagerada en su situación, creo .

El Principio de Responsabilidad Individual a menudo está en desacuerdo con el principio OO de Decir, No Preguntar . Mi sensación sobre el tema ha oscilado, y me he acostumbrado a las siguientes condiciones cuando la lógica debe entrar en un objeto de dominio:

• La lógica debe ser lógica de dominio, es decir, nada como image.load () o image.save ()
• La lógica no debería darle al objeto más que "una razón" para cambiar en el dominio. Esta es una nueva declaración del SRP.
• La lógica no debe forzarse en el objeto. En otras palabras, si termina haciendo algo así como tratar de calcular la suma de alguna propiedad en una lista de objetos de dominio sin usar un getter , piense dos veces.

En su situación, optaría por no realizar la llamada al servicio dentro del objeto de la entidad, principalmente porque el servicio no parece estar relacionado con su dominio, sino que está más relacionado con la persistencia. Los objetos de dominio deben combinarse con los conceptos de dominio, y no creo que el servicio que brindó califique.

Un ejemplo en el que creo que llamar un servicio en una entidad podría ser aceptable sería si su aplicación utilizara un servidor de flujo de trabajo de terceros para administrar partes de su estado. Básicamente, este es el patrón de estado con los estados definidos en tiempo de ejecución.

Creo que es aceptable tener domainObject.moveToNextState () (suponiendo que este código "tiene sentido" en su lenguaje ubicuo) llame al servicio que habla con su servidor porque el servidor de flujo de trabajo administra una parte del modelo de dominio.

Añadiré que DDD está muy interesado en seguir el lenguaje del dominio. ¿Escuchas a los expertos en el dominio que dicen "la imagen de un usuario encuentra si su huella dactilar coincide con la del servicio del vendedor XYZ"? ¿O dicen "El servicio del vendedor XYZ, con una huella dactilar, indica si existe la huella digital"? Ve con el que tenga más sentido en tu dominio.

Algunos pensamientos más (he pensado mucho sobre este tema porque es fundamental para el diseño):

• En el libro de Evans DDD, una entidad de cuenta tiene métodos como crédito (Importe), débito (Importe), transferencia A (Cuenta, Importe) y devenga (), pero un Servicio de transferencia de fondos tiene un método de transferencia (Cuenta, Cuenta, Importe). El método transferTo no llama a ningún servicio, sino que simplemente maneja la lógica que implica las cuentas, como el abono y el abono de los montos correctos.

  El FundsTransferService, además de la coordinación, tiene sus propias reglas para verificar, reglas que no se ajustan a las cuentas. La cantidad exacta de crédito o débito podría involucrar a partes externas. Esto hace que sea incómodo transferir para llamar al servicio.

• Para objetos simples, como UserImage, la lógica de dominio significativa que puede caber en el objeto mismo puede ser escasa porque no es, hasta donde puedo decir, un agregado. Agregados, creo, presentan más de una oportunidad para albergar la lógica de dominio. El ejemplo de Cuenta es probablemente un Agregado.

Answer 4

Creo que es mejor no llamar repositorios o servicios de entidades u objetos de valor, pero a veces es necesario, por ejemplo, si una entidad tiene que devolver otra entidad que debe cargarse de la base de datos, pero no puede navegar a ella utilizando un gráfico de objetos. Luego, el principio de inversión de dependencia viene a ayudar, lo que significa que las entidades y los objetos de valor dependen de las interfaces de servicios y repositorios y no de las implementaciones.