Anemic Re-use, Revisited

Last week, I was doing what I do best: scheming with a fellow Java developer on how to design our objects for the upcoming project. The twist is that we have a big opportunity for re-use and we had to take advantage of it to avoid painful re-implementation.

After settling on a design, I asked my partner about which layer these objects would live in: the “logic” layer, claiming to house business logic, or the “entity” layer, which apparently contains getter and setter classes.

On the project that has been the topic of recent Nowhere To Run strips, we used the entity layer because we had no complicated business logic. I was rather surprised when he said that these objects we were about to implement would best reside in the logic layer.

Anemic Re-use

Anemic Domain Models have their vices, to be sure, but there is an argument to be made for their use, and it is a compelling one: re-use.

By separating data structure from behavior, the data structure can be re-used across multiple applications which have different behavior for entities. Of course, this is a big trade-off: readability, maintainability, and encapsulation for reusability. Nothing is ever for free in this line of work.

The problem is that this is quintessentially anti-OO, and anti-domain-driven design. If you are ever to make the move to DDD in a company with a stated goal for object re-use, like mine, then this issue has to be addressed.