Design: When the line between domain objects and service objects isn't clear

Question

This question is, at it's core, a design question. I'll use a Java/Java EE example to illustrate the question.

Consider a web-mail application which is built using JPA for persistence and EJB for the services layer. Let's say we have a service method in our EJB like this:

public void incomingMail(String destination, Message message) {
    Mailbox mb = findMailBox(destination); // who cares how this works
    mb.addMessage(message);
}

This is seemingly a reasonable business method. Presumably, the Mailbox object will still be attached and it will seamlessly save the changes back to the database. After all, that is the promise of transparent persistence.

The Mailbox object would have this method:

public void addMessage(Message message) {
    messages.add(message);
}

Here's where it gets complicated -- assume we want to have other mailbox types. Say we have an AutoRespondingMailbox which automatically responds to the sender, and a HelpDeskMailbox which automatically opens a helpdesk ticket with each email received.

The natural thing to do would be to extend Mailbox, where AutoRespondingMailbox has this method:

public void addMessage(Message message) {
    String response = getAutoResponse();
    // do something magic here to send the response automatically
}

The problem is that our Maibox object and it's subclasses are "domain objects" (and in this example, also JPA entities). The Hibernate guys (and many others) preach a non-dependent domain model -- that is, a domain model that does not depend on container/runtime provided services. The issue with such a model is that the AutoRespndingMailbox.addMessage() method cannot send an email because it can't access, for example, JavaMail.

The exact same issue would occur with HelpDeskMailbox, as it could not access WebServices or JNDI injection to communicate with the HelpDesk system.

So you're forced to put this functionality in the service layer, like this:

public void incomingMail(String destination, Message message) {
    Mailbox mb = findMailBox(destination); // who cares how this works
    if (mb instanceof AutoRespondingMailbox) {
        String response = ((AutoRespondingMailbox)mb).getAutoResponse();
        // now we can access the container services to send the mail
    } else if (mb instanceof HelpDeskMailbox) {
        // ...
    } else {
        mb.addMessage(message);
    }
}

Having to use instanceof in that way is the first sign of a problem. Having to modify this service class each time you want to subclass Mailbox is another sign of a problem.

Does anyone have best practices for how these situations are handled? Some would say that the Mailbox object should have access to the container services, and this can be done with some fudging, but it's definitely fighting the intended usage of JPA to do that, as the container provides dependency injection everywhere except in Entities, clearly indicating that this isn't an expected use case.

So, what are we expected to do instead? Liter-up our service methods and give-up polymorphism? Our objects automatically become relegated to C-style structs and we lose most of the benefit of OO.

The Hibernate team would say that we should split our business logic between the domain layer and the service layer, putting all of the logic that's not dependent on the container into the domain entities, and putting all the logic that is dependent on the container into the services layer. I can accept that, if someone can give me an example of how to do that without having to completely give-up polymorphism and resorting to instanceof and other such nastiness

Answer 1

You're missing something: it's completely sensible for the Mailbox object to depend on an interface that's provided at runtime. The "don't depend on runtime services" is correct, in that you shouldn't have compile-time dependencies.

With the only dependency being an interface, you can use an IoC container like StructureMap, Unity, etc. to feed your object a test instance as opposed to a runtime instance.

In the end, your code for an AutoRespondingMailbox might look like this:

public class AutoRespondingMailbox {
    private IEmailSender _sender;

    public AutoRespondingMailbox(IEmailSender sender){
        _sender = sender;
    }

    public void addMessage(Message message){
        String response = getAutoResponse();
        _sender.Send(response);
}

Note that this class does depend on something, but it's not necessarily provided by the runtime - for a unit test, you could easily provide a dummy IEmailSender that writes to the console, etc. Also, if your platform changes, or requirements change, you can easily provide a different IEmailSender on construction that uses a different methodology than the original. That is the reason for the "limit dependencies" attitude.

Answer 2

a mailbox is a mailbox...

...but an autoresponding mailbox is a mailbox with some rules attached to it; this is arguably not a subclass of mailbox, but is instead a MailAgent that controls one or more mailboxes and a set of rules.

Caveat: I have limited experience with DDD, but this example strikes me as based on a false assumption, e.g. that the behavior of applying rules belongs to the mailbox. I think applying rules to messages is independent of the mailbox, i.e. the recipient mailbox may be only one of the criteria used by filtering/routing rules. So an ApplyRules(message) or ApplyRules(mailbox, message) service would make more sense to me in this case.

Answer 3

I'm not too experienced with DDD, but I have one suggestion to how this could be solved.

I would have made the MailBox-class abstract and then made the 3 implementations with MailBox as their superclass.

I think that the naming of the method addMessage(...) could be done better. This name - add is suggesting that the provided message should just be added to the mailbox, just like a setter, but instead of replacing an existing value it just adds the provided message to some kind of storage.

But what you are looking for is rather a behavior. What if the abstract mailbox forced all subclasses to implement the method public void handleIncommingMessage(Message message);?

Then your method findMailBox(destination); decides somehow which mailbox-instance that should be retrieved, which already is its responsibility.

When instanciating the different subclasses of the mailbox, each subclass might have different needs on how to handle an incomming message. But this can be separated doing the following:

Functional interface:

public interface MessageHandler {
    void handleMessage(Message message);
}

Abstract class:

public abstract MailBox{
    private MessageHandler handler;

    protected MailBox(MessageHandler handler){
        this.handler = handler;
    }

Instanciation:

 MailBox mb1 = new MailStorage(new DefaultMessageHandler());
 MailBox mb2 = new AutoreplyingMailBox(new AutoReplyingMessageHandler()); 
 MailBox mb3 = new HelpDeskMailBox(new HelpDeskMessageHandler());

And if you want, you could even get rid of all the different subclasses of the MailBox and instead just make different implementations of the MessageHandler-interface.

Depending on what destination that is provided to the findMailBox-method, you would just need to instanciate a MailBox (non-abstract in this case), and provide it with the correct MessageHandler-implementation.

That would make the MailBox.handleIncommingMessage(...) only do one thing (or two):

public class MailBox {

    private MessageHandler messageHandler;

    public MailBox(MessageHandler messageHandler){
         this.messageHandler = messageHandler;
    }

    public void handleIncommingMessage(Message message){
         addMessage(message);
         this.messageHandler.handleMessage(message);
    }
}

The final code in your example would then be something like this

public void incomingMail(String destination, Message message) {
    Mailbox mb = findMailBox(destination); // who cares how this works
    mb.handleIncommingMessage(message);
}

This method will never have to be edited when a new type of MailBox or MessageHandler is introduced. The logic is separated from the data, the logic for what happens when a message is added (addMessage/handleIncommingMessage) is kept in the MailHandler-implementation.