Kinda tangentially related to this discussion, I'm often asked whether I believe in rich domain models or anemic domain models. I guess I'm pretty much ignorant as to what these terms really mean, since I've never seen a proper definition of either term.

If by anemic domain model, we mean /never/ writing any business logic on our object model, and if by rich domain model, we mean /writing as much business logic as possible/ on our domain model, then I certainly don't believe in either approach. But these seem to be caricatures; I don't think anyone follows either extreme.

So how do /I/ decide if method that implements business logic might belong on the domain model?

Well, here I'm guided by an understanding that the domain model (entity classes) are /the most reusable/ classes in my codebase. So I don't want to put any logic there that has dependencies to any state or collaborating classes /other than/:

• state held in the domain model (the persistent attributes), and
• other domain model classes.

In particular, I would never write code that calls out to external services, or accesses the database, or calls an EJB/Seam/Spring component in my entity class. I want my domain model to be /completely self-contained!/

So anytime you find yourself wishing that entities supported injection, or find yourself writing a JNDI lookup in a method of an entity, please consider that your domain model is no longer self-contained, and will be less reusable in different execution environments.

I'm not saying it's /wrong/ to disobey these rules. There's no right or wrong in design. But I think there's good value having a self-contained domain model, and I've never seen a situation where this idea was impractical.