Avoid externalizing decisions from your domain model

time to read 3 min | 437 words

I recently saw an entity that looked something like this:

public class Prisoner
    public virtual bool CanBePutInIsolation() { ... }
    public virtual bool IsEligibleForVacations() { ... }
    public virtual bool CanSendToWork() { ... }

I won’t show the logic in those methods, but it was fairly involved and very business focused. It is also, incidentally, caused my rhino sense to tingle. It didn’t surprise me to find out that the UI looked like this:


Well, the logic is well encapsulated, and it clearly is business logic. Why should I care where I am actually putting it? Isn’t the place of domain logic in the… domain?

Yes & no. The problem that I have here is that those are query methods that are only going to be used in the UI. There is no business logic in the application that actually uses them, it is only the UI that will call them to make presentation decisions.

There are actually several issues here, first, and I want to make it clear, this is not an issue of mixing presentation logic in the entities. Next, and the reason that my rhino sense tingled is the presence of a Boolean query method  on the entity. Every time that I see one I become very suspicious. Boolean methods worry me because of their implications. If you have a Boolean method here, it means that somewhere else you have an if statement that works based on this method.

And at that point, you really have to ask yourself if this is an appropriate decision to make. Usually, I find, you can avoid it by moving the responsibility into the domain. But what about this case? I can’t really move the responsibility for creating the UI into the entity, after all. And somewhere in the application I must have this knowledge so I can build my UI.

I am not going to try to answer this question at this moment. I have my own thoughts about the subject, but I would like to have additional feedback about this from the community.