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.
