domain driven design – DDD Validator Specification with dependency on repository


When you inject repositories or other dependencies into the domain, the domain becomes less pure. Impure domain models are harder to test and reason about. Therefore pure domain models are preferred.

So, how would it be possible to satisfy the two conditions below, without injecting a repository?

I can’t have the property Color with value “Red” if there are 10 or more entity Car with the Color = “Red”.

I can’t have the property Color with value “Red” if the entity “Warehouse” haven’t the entry with item code “FF0000”.

The Car entity could have a method or constructor that takes the required information as arguments, instead of fetching it from a repository. For example:

public static Car Create(Model model, Engine engine, Color desiredColor, IReadOnlyList<ColorCount> usedColors, IReadOnlyList<Color> availableColors)
{
   // do validation on usedColors and availableColors
   return new Car(model, engine, desiredColor);
}

Before calling this method from an application service, you fetch the information from the repository. The usedColors collection contains the number of times each color is used and the availableColors collection contains all the colors in the warehouse.

This way, all decisions can be made inside the domain, without any out-of-process dependencies.