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

It's all in your head - consider rotation service to be a part of the domain model and the problem dissolves.

Rotation needs to keep information about many employees, so it belongs to neither lead, nor to any single employee object. It does to deserve to be a domain object in itself.

Just renaming "RotationService" to something like "Organization.UserSupportDepartment" makes it obvious.