I thought it was interesting to hear Eric Evans in a recent InfoQ interview say (emphasis mine):
I became more and more aware that one of the basic mistakes that model enthusiasts made from the start was the idea that we should just model everything, that the whole system should modeled and object oriented and so on. what I have started to realize is that that dilutes the effort to the point where we don’t really ever get the bang for the modeling buck and that in fact most systems are probably 90% CRUD (create, read, update, delete) and that there are simpler solutions to that problem
This is an excellent point. A good number of people are getting good bang for their buck from alternative (there’s that word again, damn) approaches like active record (SubSonic, Castle ActiveRecord, and Rails ActiveRecord to name a few).
Domain model, as a pattern, represents a significant technical risk and really shouldn’t be entered in to lightly. Look for areas where there is a lot of logic or complexity and maybe consider deploying it in a targeted fashion.
Still this doesn’t mean we need to throw the baby out with the bathwater. Patterns such as entity, service, and repository can almost universally benefit any application architecture, even very simple ones.
Inversely and in light of the ubiquity of entity and repository patterns, I think people often misapply the anemic domain model anti-pattern. It is only an anti-pattern when you see/smell/feel it in a complex problem. For the run of the mill, plain jane parts of our software it’s probably not the end of the world or even a problem. Active record or even table module is a fine choice for many simpler applications or even mixed in with models in a kind of dropstone architecture (where active record is the sediment and domain models are the dropstones). Do, say, a risk analysis domain model in an anemic fashion and you’re leaving a lot of value on the table in terms of encapsulating complexity, testability, and codebase organization. The anti-pattern fits there.
In our software we have a number of areas that are fairly simple but we still say they “live in the model layer.” Do they represent a full blown domain model? No. Do they live in the same layer as complex business logic? Yes. Do we employ the armada of DDD practices in the complex areas of our application? Well, we try to get better at applying them where they fit (where is key) every day.