Domain Driven Design – просто о сложном. Дмитрий Науменко.

Доклад Дмитрия Науменко на Съесть собаку #8. PHP. 20/04/17

Для всех участников восьмой встречи “Съесть собаку” и наших подписчиков Дима собрал список из 4 ресурсов и книг, которые точно пригодятся в работе.

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

По сути, эта книга кратко пересказывает то, о чем писал Эрик Эванс в «DDD».

Хорошо описана теория и практичные советы, касающиеся вопросов анализа, проектирования, реализации и оптимального управления проектами.

Кратко почитать о правилах построения чистой архитектуры в блоге Роберта Мартина.

[mqhamdam]

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

[maxvanyushkin]

Спасибо, Дмитрий. все коротко и по делу, без лишней воды.

[vadymradvansky]

DTO используется для передачи данных между слоями. Ок.
Пример "AddressDto" имеет метод "fromRequest". В каком слое должен тогда лежать такой DTO?
Если его положить в слой контроллеров, то получается слои, расположенные ниже, будут знать о DTO из уровня контроллеров (фактически слоя инфраструктуры раз мы уже знаем о реквесте). Если его положить в какой то слой ниже, то слой ниже должен знать о деталях имплементации слоя выше включая как именно данные будут передаваться (POST). То есть если мы надумаем передавать данные через GET, то изменения затронут не только уровень инфраструктуры, а и уровень апликейшена (доменных сервисов).

Я думаю правильная имплементация подобного DTO должна содержать только метод "load(array $data)", а использоваться в контроллере "(new

[АртёмФещенко-пе]

Прекрасный доклад и интересные вопросы к нему. Спасибо

[kit]

В конце понравилось что меня раскусили. Попробовал смотреть на 1.75 и решил что хочу кайфануть, потому 1.25 использовал. Немного триггерило слово итем. :) Но со временем смирился с таким вариантом, будем считать это частью диалекта. :) Лайк тебе за доклад.

[atomicru]

Хорошее введение в DDD. Спасибо за доклад!

[kinordikus]

Самое адекватное объяснение DDD, на мой взгляд.

[a.batorsky]

4:53
Вопросы:
- почему связи задом-наперед;
- почему клиент не может существовать без счета;
- почему у клиента не определены типы данных.
Стоит ли смотреть дальше?

[SiteBizzona]

Хорошая подача материала, но есть один момент интересный, рассматривались простые action и использование в них сервисов, но как поступить в случае, когда есть просто action для вывода gridview и внутри этого action необходимо отдать на view dataProvider - в таком случае если делать сервис, который делает выборку данных и отдает затем ActiveDataProvider немножко выглядит странным. Этот вопрос из серии когда толстый контроллер пробую сделать тонким через сервис.


return $this->render('index', [
'dataProvider' => $this->serviceData->getActiveDataProvider(),





public function getActiveDataProvider() : ActiveDataProvider
{
$dataProvider = new ActiveDataProvider([
'query' => $this->getData(),
]);



return $dataProvider;

}

[magnumataredfox]

Очень интересно, но нет последовательности, вначале говорилось что Client это Entity, потом он вдруг стал агрегатом? Что за?

[libvirt_fan]

47:40 - В 2017-м поисковых систем не было по-моему ещё, если не ошибаюсь... GPT уж точно не было чтоб спросить о разнице (как 2024-м). :)

[ДенисБосый-юр]

У вас на UML диаграмме направление отношения агрегации неверное

[vadymradvansky]

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

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

Валидироваться должны входящие данные на самом верхнем уровне. Как возможное решение каждый кусок бизнес логики (фактически каждый метод сервиса) должен всегда принимать DTO наполненный волью обджектами, а вот сам DTO должен валидироваться. Если валидация DTO написана неправильно и невалидные данные просочились ниже по слоям - только Exception спасет отца русской демократии, а валидацию DTO нужно улучшить.

[ДенисШироков-эв]

хороший доклад, но объясняет лишь часть подхода DDD. Тот чел, который в конце доклада задавал вопросы про основополагающие идеи DDD прям в точку бил, ведь в примере доклада они никак не представлены

[vitalyalyokhin]

Оператору незачёт, докладчик крупным планом, код издалека - ничего не разобрать.

[maksimepikhin]

А можно будет все эти примеры как-то посмотреть текстом, если есть?

[iashumov]

Меня одного смутило на 4:54 что UML не верно записан и направление агрегации и композиции обратное?

[davaite_pro_it]

я так и не понял, DDD это просто набор шаблонов и советов которые можно применять как душе угодно?

[mclotos]

Всё супер, но мне не понятно если например у нас тот же самый Client или Item понадобится где-то в другом домене, вот так получилось что структура класса Client для этого домена такая же как и у другого домена, копипастить?
И по поводу независимости домена от базы данных и неизменяемости VO. Предполагается что при инициализации домена, мы уже передали в него всю необходимую информацию и на время работы с доменом вообще не обращаемся к базе данных?
И если Position это Entity, то почему у него нет идентификатора?

[nazar]

кпц недовольные некоторые зрители, 0 уважения, типо "понятно ты не знаешь, идем дальше".