Refactoring insight: should I really have a separate domain service for that, or is it the responsibility of an existing entity?

This insight follows on from an earlier article where I identified that the business rule “when an employee leaves the organisation, all their assets must be returned” was part of the domain model, and not just a matter of cleaning up foreign keys in the database.

I originally implemented this rule as part of a dedicated domain service called IPersonTerminatorService. Later on, I refactored it out into a standalone IAssetReturnerService to satisfy the single-responsibility principle.

asset-returner-service

But this morning I realised something: in real life, it’s the employee himself who returns all his stuff — not some other process. By taking this responsibility away from the Employee class I’ve committed two sins: creating a fictional concept in the domain, and reducing the capabilities of the Employee (leading to an anemic data-only domain model).

Time to give this responsibility back to the employee:

employee

2 thoughts on “Refactoring insight: should I really have a separate domain service for that, or is it the responsibility of an existing entity?

  1. I know this post is old, but well, it’s worth the shot… :)

    As HuntSoul said, the Domain Model should not know about the repository. In the CQRS there’s not even a repository.

    Shouldn’t be better to just invert the dependencies and pass an ‘IAssetReturnerService’ to ‘Employee.ReturnAllIssuedAssets’? That way the responsibility is fully encapsulated in the domain and it’s depending on an external (external in the view of the entity, not the domain) service.

Comments are closed.