just one thing. Make no mistake, there is a principle like that. A function should do one, and only one, thing. We use that principle when we are refactoring large functions into smaller functions; we use it at the lowest levels. But it is not one of the SOLID principles—it is not the SRP. (...) the final version of the SRP is: A module should be responsible to one, and only one, actor." Liabilities Certain liabilities the programmer must consider are introduced by using an anemic domain model: Logic cannot be implemented in a truly object-oriented way. Violation of the encapsulation and information hiding principles. Needs a separate business layer to contain the logic otherwise located in a domain model. It also means that domain model's objects cannot guarantee their correctness at any moment, because their validation and mutation logic is placed somewhere outside (most likely in multiple places). Needs a service layer when sharing domain logic across differing consumers of an object model. Makes a model less expressive. Example An anemic domain model would have one write code like the following (written in C#), which by itself does not implement any of the business concerns, in this case, that a height or a width cannot be zero or negative, or that somewhere else there is a requirement for the area of the rectangle. This means that those functionalities are implemented somewhere else, no longer on the "business" side of the program, but somewhere else hidden within its architecture. class Rectangle { public int Height { get; set; } public int Width { get; set; } } A non-anemic rewrite of the above class could look like the following. The business concerns are now handled in the domain object, while the architecture can be more domain-agnostic. class Rectangle { public int Height { get; } public int Width { get; } public Rectangle(int height, int width) { if (height <= 0) { throw new ArgumentOutOfRangeException(nameof(height)); } if (width <= 0) { throw new ArgumentOutOfRangeException(nameof(width)); } Height = height; Width = width; } public int Area() { return Height * Width; } } See also Plain old Java object Domain-driven design GRASP information expert, an anemic domain model is the typical result of not applying the information expert principle, i.e. you can avoid an anemic domain model by trying to assign responsibilities to the same classes that contain the data References