🤖▶️ Check out the Design Patterns Overview course by Steve @ardalis Smith!Check it out »Hide

DevIQ

Anemic Model

Anemic Model

In object-oriented programming, and especially in Domain-Driven Design, objects are said to be anemic if they have state but lack behavior. Some kinds of objects, such as Data Transfer Objects (DTOs), are expected to simply be a collection of data. However, the objects that model the behavior of the problem space within the application should use encapsulation to manage their internal state and behavior. An anemic model frequently fails to follow the Tell, Don't Ask principle, since objects cannot perform operations on their own state, but are constantly manipulated by other objects in a non-object-oriented fashion. Rich domain models provide useful behavior to clients within the system. Some code smells that may indicate an anemic domain model include exposed collection properties, and over-use of properties in general (especially setters).

What does an anemic model look like in terms of code? An anemic model tries to represent a domain object but only takes care of the properties, missing the behaviors as part of the model. So where do the behaviors go for these anemic models? The behaviors are usually extracted to service objects in a business layer.

Note: Models with properties and no behaviors can be considered persistence models. However, if the behaviors for these models are in a business layer, the models could be considered anemic.

How do you avoid anemic models in Domain-Driven Design? Keep in mind that Domain-Driven Design works well with highly-complex business models. The focus should be on working with the business domain, not the technical implementation. When the focus is more on the technical than the business, anemic models are more likely to happen. Also remember that Domain-Driven Design works in a highly-complex environment, one that makes sense to keep the business logic with the domain models.

If you are taking an object-oriented approach, anemic models are less desirable. However, if you are taking a functional programming approach with Domain-Driven Design, anemic models are expected, as functional programming takes an approach with immutable data structures and behaviors implemented as functions that operate on those immutable records.

References

Domain-Driven Design Fundamentals Pluralsight

Anemic Domain Model - Martin Fowler

Anemic Domain Model is no Antipattern

SOLID - The Next Step is Functional - Mark Seemann

Edit this page on GitHub

On this page

Sponsored by NimblePros
Sponsored