Is Anemic Domain Model a bundle of smart services and stupid object without a defined behavior?

Question

I am a bit confused about what is a anemic domain model in OOP. Is a sort of bundle of Plain Old X Object (where X stands for the language you prefer), without behaviors (and responsibilities).

class AnemicDomainClass {
    private $property;
    public function getProperty() {
        return $this->property;
    }
    public function setProperty($property) {
        $this->property = $property;
    }
}

... where all the logic is inside some services?

class SomeStuffService {
    public static function doSomething(AnemicDomainClass $class) {
        $class->setProperty(42);
    }
}

This appear at the end of AnemicDomainModel article of Martin Fowler

In general, the more behavior you find in the services, the more likely you are to be robbing yourself of the benefits of a domain model. If all your logic is in services, you've robbed yourself blind.

This means what? That is better to prefer with smart object instead of smart services.

Psychosocial

Yes. It moves behaviour from your models to services when they could be perfectly done by the model itself. – Ganny

Well, you could go as far as saying that an anemic domain model is simply not OOP. One of the biggest difference between a functional and an OO approach is that in OO, objects have data and behavior and in functional languages you have externalized behaviors that acts upon data structures. If you strip bare all your objects from behavior then you should perhaps embrace the functional paradigm fully and use an appropriate language. – Quinte

Answer 1

In general, the more behavior you find in the services, the more likely you are to be robbing yourself of the benefits of a domain model. If all your logic is in services, you've robbed yourself blind.

It means write object oriented code, instead of procedural code acting on data. Object oriented code means modeling concepts into objects that know their own attributes and behavior, and which collaborate together to represent a working solution to a problem.

Using a multi-paradigm language that happens to support OOP, does not mean you are writing object oriented code.

Birdlime