Is the anemic model a poor relation of object-oriented design?

Image could not be loaded. Archive image in Is the anemic model a poor relation of object-oriented design?, figure 1

↗ Medium

A colleague recently asked whether we'd have an anemic domain model. Anemic? I was a little unsure what he meant. After a short discussion we cleared up the terms. I knew the problem but had forgotten the name. I said we probably would. Thinking about it now, I have to admit that was silly.

Martin Fowler's article above gives an expert explanation of what an anemic domain model is. Otherwise you'll have to make do with my interpretation. In an anemic domain model, the domain classes representing the system's business entities contain no logic. They're just data carriers with setters and getters.

Fowler also rightly points out that an anemic domain model leads to an overly bulky, cumbersome application layer. All the application logic gets mixed together there, away from the domain model where it belongs. If you've built a multilayer application in the last few years, look at the size of every class with Service in its name. Are they the biggest monsters in your project, as they are in mine?

Those monsters are very hard to refactor in any meaningful way. You can turn a five-hundred-line method into five smaller ones of a hundred lines, of course. A genuine object-oriented redesign is almost unimaginable.

Every good J2EE tutorial or article tells us to divide our program into layers. We end up with a service layer for application logic, a presentation layer and a persistence layer for storage. Unfortunately, with few exceptions, they never tell us what those layers should look like. We correctly separate code with the same responsibility, such as UI and persistence, but the object design suffers. We put code that belongs in the domain model in layers where it doesn't belong at all.

What does good object design look like, and do we even need it? We lived with poor object design for years and our programs worked well. That's no reason to leave the structure alone when we know something is wrong. I've thought a lot about how to improve it, and I think Domain-Driven Design, or DDD, offers the best answer.

The key is moving application logic from the service layer, or heaven forbid the persistence layer, into the domain classes. Those classes still don't need to know how to save themselves to the database or manage transactions. A domain class can delegate a request to save to the persistence layer, for example.

The service and persistence layers should stay as thin as possible. Essentially, they translate between object representations and coordinate with the infrastructure. I don't think building applications this way is easy. The biggest problem is that we usually treat domain classes differently in code from classes in other layers.

We usually create domain objects with constructors. That leaves us with the question of how to get the classes from other layers into them. That's a subject for another article.

Here are a few more good articles on the subject.

• Domain Driven Design and Development In Practice
• Eric Evans on Domain Driven Design
• Domain Model Overuse
• Spring 2.0 vs. the Anemic Domain Model