Yii Framework

Всем привет. class Client implements StatefulInterface { private $secirutyIndetifier; private $securityRepository private $stateTransitionManager; private $state; private function __construct( SecurityRepositoryInterface $securityRepository, StateTransitionManagerInterface $stateTransitionManager ) ...

P.S. У меня вопрос, не перебор ли это с точки зрения самой задачи? :D P.S.S В псевдокоде могут быть синтаксические ошибки - не было возможности проверить) Вроде гибко получилось, но действительно для такой тривиальной задачи слишком сложно) https://habrahabr.ru/post/321892/ - очень похоже на Ваш ке...

Я в самом первом посте об этом спросил, ElisDN ответил, что использовать его можно везде, это просто удобная замена массивам и я с ним согласен. По определению DTO это объект передачи данных. Передачи между слоями или сервисами. Идеально подходит как замена ассоциативному массиву для передачи больш...

Нужны, нет у меня модели Author как таковой, а есть интерфейс AuthorInterface. Вот и советуем сделать отдельную сущность review\Author вместо интерфейса AuthorInterface. Это если очень хочется сделать review именно отдельной системой. Мне хотелось узнать как подружить 2 модуля в первую очередь и Ва...

Не согласен, раз уж пытаться обобщить регистрацию, то нужно ее все-таки разделить по способам: Email&Password Social network Смысл в том что создается по факту один и тот же User, только с разными кол-вами свойств. Но есть свойства, которые есть всегда. Что делать если появляется новый источник...

Если будете делать на каждый способ регистрации по методу - нарушите принцип открытости/закрытости. Надо делать отдельный сервис на каждый способ регистрации На данный момент у меня 2 Application сервиса, каждый из которых отвечает (каждый со своим DTO на входе) за свой способ регистрации и оба исп...

ну допустим, но дизайн всего этого престраннейший. Пожалуйста, конкретнее и как бы Вы сделали? Что-то может быть упустил, писал "на коленке". при таком подходе интерфейсы сущностей не нужны. domain\reviews\Author domain\client\Client Нужны, нет у меня модели Author как таковой, а есть инт...

namespase Domain\Service; use Domain\Entity\User\Password; use Domain\Entity\User\Hash; interface PasswordHasher { function hash(Password $password): Hash; function validate(Password $password, Hash $hash): bool; } который работает с VO домена. А реализацию уже делаем в инфраструктуре: namespase In...

Вот чтобы даже об интерфейсах, как-то не очень похоже на правду. У меня при создании комментария на вход приходит AuthorInterface, его реализует клиент или еще кто-то, кто может быть автором чего-либо на сайте, т.е. уже получается модуль отзывов знает о интерфейсах других модулей. потому и знает об...

Реализация доменных сервисов - это инфраструктура? именно собственно название само за себя говорит. вы создаете рабочую инфраструктуру для работы доменного слоя. Можете пример какой-нибудь привести? не понимаю, какие примеры надо? тут все как везде. интерфейс, реализация Реализация репозитория - да...

Вот чтобы даже об интерфейсах, как-то не очень похоже на правду. У меня при создании комментария на вход приходит AuthorInterface, его реализует клиент или еще кто-то, кто может быть автором чего-либо на сайте, т.е. уже получается модуль отзывов знает о интерфейсах других модулей. потому и знает об...

1.1) На сколько корректно когда entity из одного модуля создает entity из другого модуля? Если такое необходимо, то это у Вас один модуль. Если один, то как бы его Вы назвали и где бы Вы создавали отзыв? Отзыв могут оставлять не только клиенты. Да и клиенты еще могут писать на сайт посты на форум, ...

По поводу интерфейсов. Никакие два модуля не могут ничего знать друг о друге. Даже об интерфейсах. Вот чтобы даже об интерфейсах, как-то не очень похоже на правду. У меня при создании комментария на вход приходит AuthorInterface, его реализует клиент или еще кто-то, кто может быть автором чего-либо...

Всем привет! Накопилось много вопросов, по которым с коллегами не можем прийти к однозначному мнению. Хотелось бы спросить мнение у форумчан (часто встречаю много полезного на этом форуме) 1) Такой пример - клиент оставляет отзыв на сайте. namespace domain/client; use domain/review/Review; use domai...

Не должно быть анемичных сеттеров. А геттеры вреда не приносят. Гетеры не приносят вреда, но использование приставки get, кажется, излишним. И это как-то не доменно что-ли. Но наверно действительно не принципиально. В сущностях предпочитаю называть явно getName(), isDraft(), draft(). Иначе не понят...

zelenin писал(а): ↑2017.02.16, 23:21 в этой ветке много тем по ddd (почти все)

Везде примеры с set и get, поэтому и спросил

zelenin писал(а): ↑2017.02.16, 23:21 где угодно, лишь бы сущность была валидна

Мне казалось, это должно быть где-то в одном месте (фабрике или конструкторе сущности), чтобы сущность была валидна и чтобы не делать проверку в нескольких местах.

В последнее время довольно часто встречаю мнение, что в Entity не должно быть никаких get и set методов. Мне нравится вот такой подход наименования методов. class Client { private $id; private $name; private $surname ; public function __construct($id, $name, $surname ) { $this->id = (int)$id; $this-...

samdark писал(а): ↑2017.01.30, 13:15 Смотря как с ними работают. Если по одной через API, то внешними ключами будет логичнее.

Александр, подскажите, пожалуйста, примеры кода выше - это правильный способ в Yii2 делать репозитории (на каждую сущность свой mapper) ?
Может есть какое-то более удачное решение?

Как мне сохранять и получать aggregate? Получать: if (!$post = $this->db->createCommand('SELECT * FROM post WHERE id = :id')->queryOne([':id' => $id])) { throw new NotFoundException('Post not found.'); } $photos = $this->db->createCommand('SELECT * FROM photos WHERE post_id = :id')->queryAll([':id'...

1) Проектируйте агрегаты адекватно. Не делайте ненужных связей. Можно для экономии хранить ID связанной сущности вместо её самой, если её поля агрегату не нужны. Либо, в крайнем случае, реализуйте ленивую загрузку. 2) При загрузке сохраняйте копию извлечённого массива $row. При сохранении сравнивай...