Мне кажется, что как только люди немного узнали о DDD, они выбирают шаблон спецификации и надеются применить его повсюду. Это действительно анти-паттерн Golden Hammer .
То, как я вижу место для шаблона спецификации, и то, как я понял доменно-управляемый дизайн , заключается в том, что это шаблон проектирования, который вы можете выбрать для применения, когда вам нужно изменить бизнес-правило. независимо от сущности.
Помните, что DDD - это итеративный подход, поэтому вам не нужно понимать его «правильно» с первого раза. Я бы начал с размещения базовой проверки внутри сущностей. Это хорошо согласуется с основной идеей OOD, поскольку позволяет объекту, представляющему концепцию, знать допустимые диапазоны данных.
В большинстве случаев вам даже не требуется явная проверка, поскольку сущности должны быть спроектированы таким образом, чтобы ограничения представлялись в виде инвариантов, что делало невозможным создание экземпляра, который нарушает ограничение.
Если у вас есть правило, согласно которому имя не может быть пустым или пустым, вы можете активно применять его непосредственно в вашей организации:
public class MyEntity
{
private string name;
public MyEntity(string name)
{
if(string.IsNullOrEmpty(name))
{
throw new ArgumentException();
}
this.name = name;
}
public string Name
{
get { return this.name; }
set
{
if(string.IsNullOrEmpty(value))
{
throw new ArgumentException();
}
this.name = value;
}
}
}
Правило, согласно которому имя не может быть пустым, теперь является инвариантом для класса: теперь класс MyEntity не может попасть в состояние, когда это правило нарушено.
Если позже вы обнаружите, что правило более сложное или разделено между многими различными понятиями, вы всегда можете извлечь его в Спецификацию.