DDD архитектура

[zelenin]

все как всегда - lazy/eager loading.
в параллельной теме http://www.yiiframework.ru/forum/viewto ... 34&t=36725 обсуждали это достаточно подробно. Вкратце, самый красивый путь, не вступающий в конфликт с ddd - это прокси, но прокси не работают с final-классами. Если не юзаете final, то вперед.

Ну это все, если вы не юзаете orm, которые это из коробки делают, типа доктрины.

[zelenin]

Или вот на php примеры https://github.com/idr0id/ddd-blog/blob ... y/User.php умеют как-то по умному выбирать вложенные сабмодели через doctrine, но я эти примеры на php вообще не понимаю. Помоему сразу понятно, что сущность здесь зависит от Doctrine, то есть от инфраструктурного уровня. Стоить его сменить и весь домен нужно переписывать. Но помоему DDD как раз о другом.

верно. использование доктрины - это большая сделка с совестью, поскольку lazy подразумевает использование их ArrayCollection в связях, что является протечкой инфраструктуры в домен.

[sda]

zelenin из репозитория возвращать прокси вместо реальной сущности, который будет перехватывать все обращения от клиента и если нужно подгружать сабмодели? Прокси тогда получается должен жить в инфраструктурном слое?

[zelenin]

zelenin из репозитория возвращать прокси вместо реальной сущности, который будет перехватывать все обращения от клиента и если нужно подгружать сабмодели? Прокси тогда получается должен жить в инфраструктурном слое?

да, прокси наследует сущность, поэтому проходит проверку на instanceof, живет в инфраструктуре, и либо ручками пишется либо генерится автоматически на основе конфигурации.

[ElisDN]

В общем в теории все красиво, но кто бы на практике показал.

Эванс - теория, Вернон - практика. Прочитайте и вторую книгу.

[sda]

zelenin а фабрики для создания сущностей в каком слое должны жить?

[zelenin]

zelenin а фабрики для создания сущностей в каком слое должны жить?

домен

[slavcodev]

Код: Выделить всё

class ThreadRepository
{
  public function findThread($id)
  {
      return $this->build($this->query("SELECT * FROM threads WHERE id = :id", ['id' => $id]));
  }
  
  private function build($threadData)
  {
    return new Thread($threadData['title'], $threadData['body'], $threadData['author'], $this->postsRepository);
  }
  
  public function store(Thread $thread)
  {
     // start transaction
     // save thread
     // process dirty posts
     // end transaction
  }
}

class Thread
{
  public function getPostsSegment($limit, $offset)
  {
    return $this->postsRepository->getThreadPostsSegment($this->id, $limit, $offset);
  }
  
  public function getPostsCount()
  {
    return $this->postsRepository->getThreadPostsCount($this->id);
  }
  
  public function addThread(Post $post)
  {
     // тут можно $this->postsRepository->addPostToThread($post, $this->id);
     // но чтоб не бороться с совестью. и не ревьювить все,
     // лучше не давать возможность сделать такое сохранение вне агрегата
    // поэтому в репозиториях связанных сущностей не делаются методы сохранения
    // сохранение только в репозитории агрегата
     $this->postsUow->add($post);
  }
  
  public function modifyThread(Post $post)
  {
     $this->postsUow->modify($post);
  }
  
  public function removeThread($postId)
  {
     $this->postsUow->delete($postId);
  }

  public function getDirtyPosts()
  {
    return $this->postsUow;
  }  
}

interface PostRepository
{
  public function getThreadPostsSegment($threadId, $limit, $offset)
  public function getThreadPostsCount($threadId)
}

[Melodic]

Есть команда создания сущности, она передаётся в шину команд. После выполнения команды мне в экшене нужно узнать ID новосозданной сущности, что бы сделать редирект на страницу редактирования. Но т.к. команда не возвращает результат, как правильно будет узнать ID?

[zelenin]

повторю то, что написал в личке и разверну: шина не подразумевает этого, т.к. в основном полагается, что шина - черная дыра, и возможно/вероятно асинхронна, хотя на некрупных проектах она может быть и синхронной. А это значит, что самым правильным вариантом будет переделать свой паттерн с редиректа на сущность на редирект на листинг.
Даже если мы сгенерим id и добавим его в команду, которую кинем в шину, а потом сделаем редирект на view/$id, то не факт, что найдем там страницу, а не 404, т.к. реализация шины возможно/вероятно асинхронна, и запись еще не создана, или не синхронизирована из write-хранилища в read-хранилища.

[slavcodev]

Даже если мы сгенерим id и добавим его в команду, которую кинем в шину, а потом сделаем редирект на view/$id, то не факт, что найдем там страницу, а не 404, т.к. реализация шины возможно/вероятно асинхронна, и запись еще не создана, или не синхронизирована из write-хранилища в read-хранилища.

Ну если стоит задача редиректа на страницу только что созданной сущности, значит задача синхронного создания, никакого асинхронна не поддерживается, значит экшен должен запустить команду создания с определенным заранее сгенерированным ИД, и ждать выполнения, и только потом делать редирект. Конечно рассмотреть смену редиректа на список нужно, но советовать менять бизнес требования из-за проблем имплементации это совсем не верно.

[zelenin]

Даже если мы сгенерим id и добавим его в команду, которую кинем в шину, а потом сделаем редирект на view/$id, то не факт, что найдем там страницу, а не 404, т.к. реализация шины возможно/вероятно асинхронна, и запись еще не создана, или не синхронизирована из write-хранилища в read-хранилища.

Ну если стоит задача редиректа на страницу только что созданной сущности, значит задача синхронного создания, никакого асинхронна не поддерживается, значит экшен должен запустить команду создания с определенным заранее сгенерированным ИД, и ждать выполнения, и только потом делать редирект. Конечно рассмотреть смену редиректа на список нужно, но советовать менять бизнес требования из-за проблем имплементации это совсем не верно.

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

[sda]

zelenin а если я хочу для клиента отдавать не все поля сущности и хочу некоторые поля вычислять на основе других полей, а не хранить их в базе, то мне следует создать DTO для этого ?

[zelenin]

zelenin а если я хочу для клиента отдавать не все поля сущности и хочу некоторые поля вычислять на основе других полей, а не хранить их в базе, то мне следует создать DTO для этого ?

dto следует использовать для передачи данных от юзера к сущности. то есть ответ "да".

[slavcodev]

все верно, но вероятно, что на самом деле здесь не бизнес требования, а требования традиционных паттернов создания crud.

RESTful приложения тоже перенаправляют на созданную сущность а не на коллекцию.

[ElisDN]

RESTful приложения тоже перенаправляют на созданную сущность а не на коллекцию.

Тот же паттерн с прегенерированным id: получаем из секвенции nextId(), отправляем его в команду и на него перенаправляем.

[samdark]

Закрыл тему-монстра. Давайте попробуем отдельные вопросы обсуждать в отдельных темах...