anemic domain model and domain services

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.

Answer 2

Domain Services are necessary when you have a Domain Model because there is functionality that's not a part of your entities.

Think for example about a Repository or a Factory. The interface for a Repository will probably be in your Domain Layer but the implementation in your Infrastructure Layer. With a Factory, both the implementation and interface will be in your Domain Layer.

These Domain Services are used from your Application Layer. The goal of an application layer is to make sure that everything is in place so the Domain Model can do his work. This could mean loading specific entities from Repositories and then calling domain specific functions on them.

Validation should go inside an Entity. For example, lets suppose you have a Money class.

public class Money
{
    public Money(string currency, int amount)
    {
        Currency = currency;
        Amount = amount;
    }

    public int Amount { get; set; }

    public string Currency { get; set; }
}

If the Money class is not allowed to have a negative amount, where would you validate this?

The best place to do this is inside the class. An entity is responsible for its own state. In a Money class, this is easy to see but for example with an Order class with OrderLines the Order is responsible for checking if there are duplicate OrderLine items that should be merged (saves shipping costs!)

Answer 3

Domain Services usually contain domain functionality that doesn't naturally fit into one of your entities. It's often functionality that is required by many other domain objects, potentially making the domain service a big nexus where many objects connect.

As for validation, it can be in various places depending on when and what you want to validate :

• Factories enforce invariants upon creation of an entity

• Aggregate roots enforce invariants that concern the whole aggregate

• Basic validation is also often performed inside the entities themselves

• You can have custom validation that requires data related to the current state of the application, in which case the validation is more likely to be done in the Application layer.