DDD - Ответственность за создание и проверку сущности

Question

В последние дни меня интересует DDD (Domain Driven Design), но я не могу понять, кто занимается созданием и проверкой сущностей.Я разобью этот вопрос, чтобы охватить разные сценарии.

1. Обычная сущность (возможно, с объектом значения).В качестве примера рассмотрим пользователя, который идентифицирован по электронной почте.У меня есть UserFactory, которая получает массив данных (возможно, из формы POST) и возвращает мне новый UserEntity.Должна ли фабрика проверять целостность данных (например, строка, указанная как электронная почта, представляет собой реальную электронную почту, пароли в поле пароля 1 и поле 2 совпадают и т. Д.)?Должна ли фабрика подтвердить, что такого пользователя уже нет (мы не хотим регистрировать двух пользователей с одним и тем же адресом электронной почты)?Если да, то должен ли он сделать это сам или с помощью UserRepository?

2. Совокупный объект.Предположим, у нас есть сущность Post и сущности Comments.Я хочу получить пост 12 со всеми его комментариями, поэтому я делаю что-то вроде

   $ post = $ postRepository-> getById (12);

Как должен быть getByIdреализованы?как это:

public function getById($id) {
    $postData = $this->magicFetchFromDB($id);
    $comments = (new CommentRepository())->getForPost(12);
    return new PostEntity($postData, $comments);
}

Или, может быть, пост, отвечающий за ленивое создание своих комментариев, что-то вроде:

class PostEntity {
    public function getComments() {
        if(is_null($this->_comments)) $this->_comments = (new CommentRepository())->getForPost($this->_id);
        return $this->_comments;
    }
}

?Я очень заблудился здесь, и не хватает информации с примерами для DDD в PHP, поэтому любая помощь будет оценена по достоинству!

Большое спасибо, skwee.

Answer 1

• Фабрика должна только заботиться о создании сущностей.Лично я предпочитаю ставить валидацию как в моих представлениях, так и на уровне модели.Я бы использовал некоторую библиотеку, такую ​​как плагин проверки jQuery, чтобы провести существенную проверку на стороне клиента (например, проверку наличия данных в обязательных полях).А затем выполните «хардкорную» проверку модели.Я делаю это с помощью простого абстрактного класса BaseEntity, который расширяют все сущности, и поскольку вы запросили пример, вот он:

  abstract class BaseEntity {
      public function isValid();
  }         
  
  class MyEntity extends BaseEntity {
       public function isValid() {
           //actual validation goes here
       }
   }
  

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

  class ValidationHelper {
      public static function isValidPhonenumber($value) {
          //check valid phonenumber, using a regex maybe
      }
  
      public static function isAlphanumeric($value) {
          //check for letters and numbers only
      }
  }
  

  Многие выступают против статических методов, потому что они могут нарушать модульные тесты, но в этом случае они довольно просты и не имеют внешних зависимостей, что делает их "более безопасными".

• Когда дело доходит до проверки уже существующих сущностей, вы можете сделать это, запросив вашу БД, чтобы узнать, существует ли сущность там до добавления / обновления, или (это то, как мне нравится это делать) вы можете добавить индекс unique к тем столбцам, которые не могут повторяться в БД, а затем обернуть запросы на создание или обновление в блок try-catch (запрос выдаст уникальное нарушение ограничения, если два пользователя имеютнапример, тот же адрес электронной почты), а затем покажите правильное сообщение об ошибке

• По вашему последнему вопросу это сводится к вопросу пр.правочник.Если ваша БД получит миллион обращений за 1 минуту, то, вероятно, лучше использовать отложенную загрузку, чтобы избежать выборки ненужных данных, пока они не понадобятся.Но если ваша база данных относительно мала, вы можете без проблем использовать загрузку, не жертвуя слишком большой производительностью.Опять же, это вопрос личных предпочтений.

надеюсь, что некоторые из этих бессвязных рассуждений имеют смысл, ура!

Answer 2

Лучший и самый простой способ для этого - использовать Doctrine2. Может быть, первые часы будут тяжелыми, но как только вы овладеете Doctrine2, все такие отношения и совокупность станут несложными.

Вы можете найти много информации о PHP & DDD или Doctrine2 на http://giorgiosironi.blogspot.com/ или просто по поиску.

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

Здесь много других сообщений по этим темам - попробуйте использовать вышеуказанные ключевые слова.