Question

In my mind it feels like we need an inversion of construction here.

The entity is relying upon services to populate various properties, within itself. This should be palmed off to a builder, shouldn’t it? (That is the construction of the object) I’m looking at legacy code and performing some general refactoring.

In essence the entity should be pretty dumb, there seems to be mix of processing going on it that Im pretty certain should/could be broken out.

Answer 1

Injecting services into domain entities might not be a good idea, but maybe not for the reason you think.

In essence the entity should be pretty dumb, there seems to be mix of
processing going on it that Im pretty certain should/could be broken
out.

It’s a controversial matter, but many believe that dumb domain entities is an anti-pattern (Anemic Domain Model) and goes against the object oriented style of programming. Entities should not just contain data but also encapsulate behavior.

The problem is, how much behavior can you add before your domain object starts suffering low cohesion ? In your example, relying upon services to populate various properties is a typical borderline case between what is the domain object’s responsibility (cohesive) and what isn’t. In addition, if the properties are explicitely loaded from a database, this might be a violation of the persistence ignorance principle.

If it turns out that these properties need to be initialized right from the birth of the object, I agree with you that a Factory or a Builder could be a better place to fetch that data and assemble the entity, especially if the construction logic is complex.

But usually, such a mechanism is there to provide lazy loading, in other words to populate the properties on-demand and just in time. This allows to defer costly operations such as fetching potentially big data from a database and avoids having a big object graph loaded in memory right from the start.

While I personally wouldn’t be offended to see Services injected in entities at construction time for lazy loading purposes, some consider it bad practice : see here and here. You might prefer to use method injection or delegate injection for cleaner, more testable entities.