DDD архитектура
Re: DDD архитектура
все как всегда - lazy/eager loading.
в параллельной теме http://www.yiiframework.ru/forum/viewto ... 34&t=36725 обсуждали это достаточно подробно. Вкратце, самый красивый путь, не вступающий в конфликт с ddd - это прокси, но прокси не работают с final-классами. Если не юзаете final, то вперед.
Ну это все, если вы не юзаете orm, которые это из коробки делают, типа доктрины.
в параллельной теме http://www.yiiframework.ru/forum/viewto ... 34&t=36725 обсуждали это достаточно подробно. Вкратце, самый красивый путь, не вступающий в конфликт с ddd - это прокси, но прокси не работают с final-классами. Если не юзаете final, то вперед.
Ну это все, если вы не юзаете orm, которые это из коробки делают, типа доктрины.
Re: DDD архитектура
верно. использование доктрины - это большая сделка с совестью, поскольку lazy подразумевает использование их ArrayCollection в связях, что является протечкой инфраструктуры в домен.sda писал(а):Или вот на php примеры https://github.com/idr0id/ddd-blog/blob ... y/User.php умеют как-то по умному выбирать вложенные сабмодели через doctrine, но я эти примеры на php вообще не понимаю. Помоему сразу понятно, что сущность здесь зависит от Doctrine, то есть от инфраструктурного уровня. Стоить его сменить и весь домен нужно переписывать. Но помоему DDD как раз о другом.
Re: DDD архитектура
zelenin из репозитория возвращать прокси вместо реальной сущности, который будет перехватывать все обращения от клиента и если нужно подгружать сабмодели? Прокси тогда получается должен жить в инфраструктурном слое?
Re: DDD архитектура
да, прокси наследует сущность, поэтому проходит проверку на instanceof, живет в инфраструктуре, и либо ручками пишется либо генерится автоматически на основе конфигурации.sda писал(а):zelenin из репозитория возвращать прокси вместо реальной сущности, который будет перехватывать все обращения от клиента и если нужно подгружать сабмодели? Прокси тогда получается должен жить в инфраструктурном слое?
Re: DDD архитектура
Эванс - теория, Вернон - практика. Прочитайте и вторую книгу.sda писал(а):В общем в теории все красиво, но кто бы на практике показал.
Re: DDD архитектура
zelenin а фабрики для создания сущностей в каком слое должны жить?
Re: DDD архитектура
доменsda писал(а):zelenin а фабрики для создания сущностей в каком слое должны жить?
- slavcodev
- Сообщения: 3134
- Зарегистрирован: 2009.04.02, 21:42
- Откуда: Valencia
- Контактная информация:
Re: DDD архитектура
Код: Выделить всё
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)
}
Жду Yii 3!
Re: DDD архитектура
Есть команда создания сущности, она передаётся в шину команд. После выполнения команды мне в экшене нужно узнать ID новосозданной сущности, что бы сделать редирект на страницу редактирования. Но т.к. команда не возвращает результат, как правильно будет узнать ID?
Re: DDD архитектура
повторю то, что написал в личке и разверну: шина не подразумевает этого, т.к. в основном полагается, что шина - черная дыра, и возможно/вероятно асинхронна, хотя на некрупных проектах она может быть и синхронной. А это значит, что самым правильным вариантом будет переделать свой паттерн с редиректа на сущность на редирект на листинг.
Даже если мы сгенерим id и добавим его в команду, которую кинем в шину, а потом сделаем редирект на view/$id, то не факт, что найдем там страницу, а не 404, т.к. реализация шины возможно/вероятно асинхронна, и запись еще не создана, или не синхронизирована из write-хранилища в read-хранилища.
Даже если мы сгенерим id и добавим его в команду, которую кинем в шину, а потом сделаем редирект на view/$id, то не факт, что найдем там страницу, а не 404, т.к. реализация шины возможно/вероятно асинхронна, и запись еще не создана, или не синхронизирована из write-хранилища в read-хранилища.
- slavcodev
- Сообщения: 3134
- Зарегистрирован: 2009.04.02, 21:42
- Откуда: Valencia
- Контактная информация:
Re: DDD архитектура
Ну если стоит задача редиректа на страницу только что созданной сущности, значит задача синхронного создания, никакого асинхронна не поддерживается, значит экшен должен запустить команду создания с определенным заранее сгенерированным ИД, и ждать выполнения, и только потом делать редирект. Конечно рассмотреть смену редиректа на список нужно, но советовать менять бизнес требования из-за проблем имплементации это совсем не верно.zelenin писал(а):Даже если мы сгенерим id и добавим его в команду, которую кинем в шину, а потом сделаем редирект на view/$id, то не факт, что найдем там страницу, а не 404, т.к. реализация шины возможно/вероятно асинхронна, и запись еще не создана, или не синхронизирована из write-хранилища в read-хранилища.
Жду Yii 3!
Re: DDD архитектура
все верно, но вероятно, что на самом деле здесь не бизнес требования, а требования традиционных паттернов создания crud. Хотя если задуматься, то традиционный паттерн переформулируется в бизнес-требование.slavcodev писал(а):Ну если стоит задача редиректа на страницу только что созданной сущности, значит задача синхронного создания, никакого асинхронна не поддерживается, значит экшен должен запустить команду создания с определенным заранее сгенерированным ИД, и ждать выполнения, и только потом делать редирект. Конечно рассмотреть смену редиректа на список нужно, но советовать менять бизнес требования из-за проблем имплементации это совсем не верно.zelenin писал(а):Даже если мы сгенерим id и добавим его в команду, которую кинем в шину, а потом сделаем редирект на view/$id, то не факт, что найдем там страницу, а не 404, т.к. реализация шины возможно/вероятно асинхронна, и запись еще не создана, или не синхронизирована из write-хранилища в read-хранилища.
тогда хороший вариант: генерить id в экшне и запихивать его в к команду.
Re: DDD архитектура
zelenin а если я хочу для клиента отдавать не все поля сущности и хочу некоторые поля вычислять на основе других полей, а не хранить их в базе, то мне следует создать DTO для этого ?
Re: DDD архитектура
dto следует использовать для передачи данных от юзера к сущности. то есть ответ "да".sda писал(а):zelenin а если я хочу для клиента отдавать не все поля сущности и хочу некоторые поля вычислять на основе других полей, а не хранить их в базе, то мне следует создать DTO для этого ?
- slavcodev
- Сообщения: 3134
- Зарегистрирован: 2009.04.02, 21:42
- Откуда: Valencia
- Контактная информация:
Re: DDD архитектура
RESTful приложения тоже перенаправляют на созданную сущность а не на коллекцию.zelenin писал(а):все верно, но вероятно, что на самом деле здесь не бизнес требования, а требования традиционных паттернов создания crud.
Жду Yii 3!
Re: DDD архитектура
Тот же паттерн с прегенерированным id: получаем из секвенции nextId(), отправляем его в команду и на него перенаправляем.slavcodev писал(а):RESTful приложения тоже перенаправляют на созданную сущность а не на коллекцию.
- samdark
- Администратор
- Сообщения: 9489
- Зарегистрирован: 2009.04.02, 13:46
- Откуда: Воронеж
- Контактная информация:
Re: DDD архитектура
Закрыл тему-монстра. Давайте попробуем отдельные вопросы обсуждать в отдельных темах...
Нравится Yii? Давайте сделаем его лучше!.