What is anemia in domain model?

Question

From what I can grasp from Martin Fowler, anemia means to separate business logic from domain objects, which are reduced to trivial getters and setters, while the domain behavior is moved to service layer. Do I miss something?

How can we call some object domain if it doesn't have any behavior? Can you please provide some very brief code of anemic domain model?

Answer 1

It is exhibited by code where:

the majority of code deals with passing data structures (property bags if you will) in the guise of domain objects (e.g. Account or TransactionEntity). They are 'domain objects' primarily because they have names of things that exist in the domain.

Most of the logic resides in external "services" - that contain scripts that operate on lists of (or individual) data structures. As a result the services need to access/modify internal information on the domain objects.. thus the domain objects spontaneously sprout lots of getters and setters. RIP Encapsulation.

Anemia refers to the absence or paucity of domain logic/ behavior in the domain classes.

More indicators:

• 'Ask' methods outnumbering 'Tell/Do' methods