What is the Anemic Domain Model? Why is it considered an anti-pattern by many?
Anemic Domain Model
An Anemic Domain Model is a model where domain objects primarily contain data while business rules and behavior live in separate service classes. It is often criticized because it weakens encapsulation and can result in procedural business logic spread across services. However, it is not universally wrong. Simple CRUD applications can reasonably use an anemic model, while rich domain models are more valuable when the domain contains significant business invariants and behavior.
- 1
Anemic models often expose setters and move business rules into services.
- 2
Rich domain models encapsulate invariants and operations with the data they govern.
- 3
Anemic models can be appropriate for simple CRUD and data-centric systems.
- 4
The right choice depends on domain complexity rather than ideology.
- 5
A useful test is whether business invariants can be violated by manipulating entity state directly.
Scenario Questions
0-2 years experience
- 1You need to add a method that calculates the total price of an Order. How would you organize the classes if the Order object only has fields and getters/setters versus if it contained the calculation logic?
- 2If you see a POJO that only stores data and all the validation lives in a separate service, what problems might you hit when a new discount rule is introduced?
2-5 years experience
- 1During a sprint you notice that adding a new validation rule forces changes in three different service classes. How does an anemic domain model contribute to this, and what refactoring would you suggest?
- 2Your team is debugging a bug where two related entities become inconsistent after a transaction. Explain how the lack of behavior in the domain objects could make the issue harder to locate.
5-8 years experience
- 1Design a microservice that processes financial transactions. Discuss how using an anemic domain model affects consistency, transaction boundaries, and scalability.
- 2You inherit a 200k‑line codebase that uses anemic entities everywhere. How would you approach refactoring it to reduce duplicated business logic while keeping performance acceptable?
8+ years experience
- 1Your organization wants to migrate a legacy monolith with anemic domain objects to a domain‑driven design across several teams. What architectural strategy would let you transition gradually without breaking existing services?
- 2From a long‑term maintenance perspective, compare the cost of evolving business rules in an anemic model versus a rich model across multiple product lines.
Follow-up Questions
- Can you give an example of a rule that would be duplicated across services in an anemic model?
- How would you test business invariants differently in a rich versus an anemic model?
- What impact does this pattern have on code readability for new team members?