Are Anemic Domain Models really considered harmful?

In his book Patterns of Enterprise Application Architecture, Martin Fowler describes the "Domain Model" as a complex approach to organizing business logic. The method consists of the consciousness of classes corresponding to domain model objects in data structure and behavior. At the same time, technical aspects such as data storage, authentication, authorization, and transaction management are removed from the business logic.

The pattern is implemented in two ways: 1) Rich model — data and behavior are encapsulated inside domain objects. 2) Anemic model — only data is encapsulated in the objects of the domain model, and the behavior is transferred to a separate layer of services.

Fowler and Evans consider the anemic model to be an antipattern. However, many codebases the speaker has worked with are implemented in the "anemic" model style. Many teams reported that they had a hard time implementing the “rich model” and have never succeeded. Is it just a lack of expertise or something related to the pattern? This talk is dedicated to comparing the firm and weak sides of both approaches and non-obvious details of each domain model implementation in the OOP paradigm and the functional programming style.

The code examples are in C, F#, Java, and Kotlin.

Max Arshinov

Solution Architect at EPAM Spain

Málaga, Spain


Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.

Jump to top