Domain Objects and Services

Question

In this question someone replies "You never let the domain object implementations call services by themselves!". Is this statement a hard fast rule of DDD or does it depend on your own application and architecture?

Contrived example:

As an example lets suppose we have a UserImage object in our model that gets populated from an uploaded image by a user. And then lets suppose that we can submit this image to a 3rd party service that can identify thumb prints and return an Guid if a match is found.

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);            
     }
}

What is avoided or gained by not letting domain objects call services themselves?

EDIT: are there any good online articles which discuss this specific topic?

Answer 1

One disadvantage I see is that allowing your domain object to call services may make it harder to serialize, or at least cause some issues after serializing it when someone on the other side calls its service method(s).

Answer 2

If you allow an Entity Object to call a service it is performing two roles Data Object and Service Object. Generally, each object should have on responsibility, not only in implementation but also in usage.

In your case, the lowly UserImage seems to be both an Image and a ThumbPrint Recognizer.