Anemic Domain Model (DDD)
An Anemic Domain Model is a domain model that contains little or no business logic, and whose Aggregates mainly consists of getters and setters. Specification and invariants regarding the domain logic are controlled through layers and upstream components.
Anemic Domain Model is considered to be an Anti Pattern to Domain Model.
In DDD, the Domain Layer has Domain models that contain Aggregates, which represent conceptual whole objects of the context of a domain. They should also contain behavior and logic intrinsic to the concept they abstract, within their applicable boundaries. Without this, the meaning and the role of such domain models is diluted, since Domain Logic is then often to be found in the various layers that access or control such Anemic Domain Models.
"[...]you realize that there is hardly any behavior on these objects, making them little more than bags of getters and setters. [...] Instead there are a set of service objects which capture all the domain logic, carrying out all the computation and updating the model objects with the results. These services live on top of the domain model and use the domain model for data." Martin Fowler, Anemic Domain Model
Anemic Domain Models happen when there is high technical and little domain knowledge. Designing a Domain Model closely with Doman Experts can help with identifying Domain Logic that should be made available within the Domain Model, and that should be part of Aggregates.
In [📖IDDD, pp. 14-19], Vaughn Vernon gives a brief overview why Anemic Domain Models happen, and why they are seldomly recognized as a problem, by arguing that developers are mainly used to implement data structures upfront, then behavior. He also mentions historic reasons why Anemic Domain Models are not identified as problematic: Due to the popularity of shared systems in the late 1990's, serializing data for communication became an important aspect of software design. Often, systems where designed with a strong focus on the portability of data, rather than its behavior given the domain context it should exist in.
references