Где поставить проверку глобальных правил в DDD

Я бы не рекомендовал запрещать изменение свойств в сущности, если это пользовательский ввод. Например, если проверка не прошла, вы все еще можете использовать экземпляр для отображения в пользовательском интерфейсе с результатами проверки, позволяющий пользователю исправить ошибку.

Джимми Нильссон в своем "применении доменного дизайна и шаблонов" рекомендует проверять для конкретной операции, а не только для сохранения. Хотя сущность может быть успешно сохранена, происходит реальная проверка когда объект собирается изменить свое состояние, например, "заказанное" состояние изменяется на "приобретенное".

при создании экземпляр должен быть допустимым для сохранения, Что включает проверку уникальности. Он отличается от valid-for-ordering, где нужно проверять не только уникальность, но и, например, кредитоспособность клиента, а также доступность в магазине.

таким образом, логика проверки не должна вызываться для присвоения свойств, она должна вызываться при агрегировании операции уровня, являются ли они постоянными или нет.

Edit: судя по другим ответам, правильное имя для такого "доменного сервиса" -спецификация. Я обновил свой ответ, чтобы отразить это, включая более подробный пример кода.

Я бы пошел с вариантом 3; создать сервис домен спецификации, которая инкапсулирует логику, которая выполняет проверку. Например, спецификация изначально вызывает репозиторий, но вы можете заменить его вызовом веб-службы в a последующие стадии. Наличие всей этой логики за абстрактной спецификацией будет держать общий дизайн более гибким.

чтобы запретить кому-либо редактировать имя без его проверки, сделайте спецификацию обязательным аспектом редактирования имени. Вы можете добиться этого, изменив API вашего объекта на что-то вроде этого:

public class User
{
    public string Name { get; private set; }

    public void SetName(string name, ISpecification<User, string> specification)
    {
        // Insert basic null validation here.

        if (!specification.IsSatisfiedBy(this, name))
        {
            // Throw some validation exception.
        }

        this.Name = name;
    }
}

public interface ISpecification<TType, TValue>
{
    bool IsSatisfiedBy(TType obj, TValue value);
}

public class UniqueUserNameSpecification : ISpecification<User, string>
{
    private IUserRepository repository;

    public UniqueUserNameSpecification(IUserRepository repository)
    {
        this.repository = repository;
    }

    public bool IsSatisfiedBy(User obj, string value)
    {
        if (value == obj.Name)
        {
            return true;
        }

        // Use this.repository for further validation of the name.
    }
}

ваш код вызова будет выглядеть примерно так:

var userRepository = IoC.Resolve<IUserRepository>();
var specification = new UniqueUserNameSpecification(userRepository);

user.SetName("John", specification);

и конечно, вы можете издеваться над ISpecification в ваших модульных тестов для более легкое испытание.

Я бы использовал спецификация для инкапсуляции правило. Затем вы можете позвонить, когда свойство UserName обновляется (или из любого другого места, которое может понадобиться):

public class UniqueUserNameSpecification : ISpecification
{
  public bool IsSatisifiedBy(User user)
  {
     // Check if the username is unique here
  }
}

public class User
{
   string _Name;
   UniqueUserNameSpecification _UniqueUserNameSpecification;  // You decide how this is injected 

   public string Name
   {
      get { return _Name; }
      set
      {
        if (_UniqueUserNameSpecification.IsSatisifiedBy(this))
        {
           _Name = value;
        }
        else
        {
           // Execute your custom warning here
        }
      }
   }
}

это не будет иметь значения, если другой разработчик пытается изменить User.Name напрямую, потому что правило всегда будет выполняться.

здесь

Я не эксперт по DDD, но я задал себе те же вопросы, и это то, что я придумал: Логика проверки обычно должна входить в конструктор / фабрику и сеттеры. Таким образом, вы гарантируете, что у вас всегда есть действительные объекты домена. Но если проверка включает запросы к базе данных, которые влияют на производительность, эффективная реализация требует другого дизайна.

(1) Инъекционные Сущности: впрыскивая реальности могут быть технически трудны и также очень сложно управлять производительностью приложений из-за фрагментации логики базы данных. Казалось бы, простые операции теперь могут неожиданно повлиять на производительность. Это также делает невозможной оптимизацию объекта домена для операций с группами одного и того же типа сущностей, вы больше не можете написать один групповой запрос, и вместо этого у вас всегда есть отдельные запросы для каждой сущности.

(2) инъекционный репозиторий: вы не должны положить любой бизнес логика в репозиториях. Держите репозитории простыми и сосредоточенными. Они должны действовать так, как если бы они были коллекциями и содержали только логику для добавления, удаления и поиска объектов (некоторые даже выделяют методы поиска для других объектов).

(3) обслуживание домена это кажется наиболее логичным местом для обработки проверки, которая требует запроса базы данных. Хорошая реализация сделает конструктор / фабрику и сеттеры, участвующие в пакете, частными, так что сущности могут быть только создано/изменено с помощью доменной службы.

в моей структуре CQRS каждый класс обработчика команд также содержит метод ValidateCommand, который затем вызывает соответствующую логику бизнеса/проверки в домене (в основном реализованную как методы сущности или статические методы сущности).

поэтому вызывающий абонент будет делать так:

if (cmdService.ValidateCommand(myCommand) == ValidationResult.OK)
{
    // Now we can assume there will be no business reason to reject
    // the command
    cmdService.ExecuteCommand(myCommand); // Async
}

каждый специализированный обработчик команд содержит логику оболочки, например:

public ValidationResult ValidateCommand(MakeCustomerGold command)
{
    var result = new ValidationResult();
    if (Customer.CanMakeGold(command.CustomerId))
    {
        // "OK" logic here
    } else {
        // "Not OK" logic here
    }
}

метод ExecuteCommand обработчика команд вызовет ValidateCommand () снова, так что даже если клиент не беспокоился, ничего не произойдет в домене, который не должен.

создайте метод, например, называемый IsUserNameValid () и сделайте его доступным отовсюду. Я бы сам поставил его в службу пользователей. Это не будет ограничивать вас при возникновении будущих изменений. Он сохраняет код проверки в одном месте (реализация), а другой код, который зависит от него, не должен будет меняться, если изменения проверки вы можете обнаружить, что вам нужно вызвать это из нескольких мест позже, например, пользовательский интерфейс для визуальной индикации без необходимости прибегать к исключению обращение. Уровень сервиса для корректных операций и репозиторий (кэш, БД и др.)) слой, чтобы убедиться, что сохраненные элементы действительны.

Мне нравится вариант 3. Простая реализация может выглядеть так:

public interface IUser
{
    string Name { get; }
    bool IsNew { get; }
}

public class User : IUser
{
    public string Name { get; private set; }
    public bool IsNew { get; private set; }
}

public class UserService : IUserService
{
    public void ValidateUser(IUser user)
    {
        var repository = RepositoryFactory.GetUserRepository(); // use IoC if needed

        if (user.IsNew && repository.UserExists(user.Name))
            throw new ValidationException("Username already exists");
    }
}

создать доменную службу

или я могу создать доменную службу для создание и редактирование пользователей. Но кто-то может напрямую редактировать имя пользователя без вызова этой службы...

Если вы правильно спроектировали свои объекты, это не должно быть проблемой.