CodeParkAn anemic domain model has domain objects that hold only data. They have getters and setters but no behaviour. All the rules live in service classes that change these objects. Example: an Order with public fields, plus an OrderService that checks the status, recalculates totals and sets the fields. This is anemic.
Martin Fowler calls it an anti-pattern because it looks like an object model, but it is really procedural code. Data and behaviour are separated, so the invariants (rules that must always be true) are not protected. This causes two problems:
- Any code can set
order.status = "shipped"and skip the checks. - The same rule gets written again in several services.
A rich domain model keeps behaviour with the data. For example, order.ship() checks the rules and then changes the state. Services only coordinate the work: they load the object, call the domain and save the result.
Anemic models are acceptable for simple CRUD apps with little business logic. The problem starts when complex rules get spread across many services.
- An anemic model has data-only entities, and the logic lives in services.
- It is procedural code that looks like objects, so invariants are not protected.
- The same rules get duplicated across several services.
- A rich model puts behaviour on the entity, and services only coordinate.
- An anemic model is fine for simple CRUD apps with little logic.