Question

If domain entities aren’t anemic, so they embed specific-usage behavior inside themselfes, is there a need/point to use/build specific domain services? How about validation should it go inside an entity?

What way is more flexible for unit testing?

Thanks!

Answer 1

Typically when an anemic model is not being used, you’ll still have needs that require domain specific services. That’s because the non-anemic models (or just, models, if you will) should contain code that allows themselves to be manipulated, but should refrain from taking dependencies on other models, especially models that are not directly related through a parent/child relationship.

Separate domain services will allow you to maintain that separation and still provide rich functionality, since they domain services can potentially be aware of a larger view of the entire domain model.

As for validation, it is not uncommon for these models to provide their own validation, just remember that sometimes the valid state of a model depends on a larger context that the model may not be aware of, so external validation is probably still going to exist.

Lastly, unit-testing flexibility is going to depend quite a bit on your application, and the underlying technology (such as language choice). I haven’t seen many cases where either approach has enough influence on unit testing by itself.