Encapsulating a service call within an domain object method

Question

Is this a valid object design ? I have a domain object where i inject a service and call a verify method to update the state of the object and if all goes well send a confirmation message. The code looks like:

class Foo {
  String bar
  Service emailService


  public boolean verify() {
    bar = "foo"
        if(this.save()) {
            emailService.sendConfirmation()
        }
  }
}

Foo.get(1).verify()

Is it acceptable to call the emailService in such a away ? is there a design pattern that i can follow to use for such a situation.

Thank you - Ken

Answer 1

There is nothing wrong with calling a service from an entity. There are, however, some problems concerning instantiating these services. If you follow this path, you have to somehow obtain an instance of a service during entity creation which is problematic.

Calling a constructor directly is obviously a bad idea (since it couples the entity to the service implementation).

Jimmy Bogard explained why injecting services into entities is a bad idea.

Instead of it, he suggested using 'double dispatch' (there were some debates if this name is appropriate) pattern to solve this problem. In this approach, a domain method callee provides a service implementation to the domain method. In your case it would look something like that:

class Foo {
  String bar    

  public boolean verify(Service emailService) {
    bar = "foo"
        if(this.save()) {
            emailService.sendConfirmation()
        }
  }
}

Foo.get(1).verify(new Service(...))

The last (but not least) option is to use Domain Events pattern. You can read about it on Udi Dahan's blog. In this approach entities are only responsible for publishing meaningful events which are subscribed by proper handlers. You can read full comparison of all these techniques on my blog.

Hope that helps

Answer 2

I'll usually send the confirmation from the place (action?) where from verify will be called. If the outcome of verify would be to send many confirmation emails then I'd probably have Foo generate and return ConfirmationMessages (a domain object) which would encapsulate all knowledge for a confirmation. The action would then be able to queue these messages for dispatch.

Having said that, if your Service is an Interface and you can inject mock for testing and the real one on production, then it looks good. Although I think it's best that domain objects hold knowledge and logic about themselves and not about systems (services) in another layer.

Answer 3

Bad thing about this is that You lose isolation of Your domain model. Your domain model knows about email service which is pure infrastructure stuff.

It might be a good idea to introduce application service. Eventing pattern would do the trick too.