Avoiding anemic domain model - a real example

Question

I am trying to understand Anemic Domain Models and why they are supposedly an anti-pattern.

Here is a real world example.

I have an Employee class, which has a t

Answer 1

I think your design is fine here. As you know, the anemic domain model anti-pattern is a backlash against the trend of avoiding any behaviour coded in domain objects. But conversely it doesn't mean all behaviour relating to a domain object must be encapsulated by that object.

As a rule of thumb, behaviour that is intrinsicly tied to the domain object and is defined entirely in terms of that one domain object instance can be included in the domain object. Otherwise, to keep responsibilities clear, it's best to put it externally in a collaborator/service like you have done.