Avoiding anemic domain model – a real example

In this case this doesn’t constitute an Anemic Domain Model. An Anemic Domain Model is specifically about validating and transforming the objects. So an example of this would be if an external function actually changed the state of the Employees or updated their details.

what is happening in this case is you are taking all of the employees and making a selection of one of them based on their information. It is fine to have a separate object that examines others and makes decisions with regard to what it finds. It is NOT ok to have an object that is used to transition an object from one state to another.

An example of an Anemic Domain Model in your case would be to have an external method

updateHours(Employee emp) // updates the working hours for the employee

that takes an Employee object and updates its hours worked for the week, making sure that flags are raised if the hours exceed a certain limit. The problem with this is that if you only have Employee objects then you have no knowledge of how to modify their hours within the correct constraints. In this case the way to deal with it would be to move the updateHours method into the Employee class. That is the crux of the Anemic Domain Model anti pattern.

Leave a Comment

Hata!: SQLSTATE[HY000] [1045] Access denied for user 'divattrend_liink'@'localhost' (using password: YES)