Просто о сложном - Domain Driven Design [ru] / Дмитрий Науменко

Конференция PHP fwdays'17 прошла 11 июня 2017 года в Киеве, Украина.
Таймкоды:
01:29 Domain - Счёт на оплату
02:13 Domain experts
04:35 Начало проэкта
10:28 Onion architecture
18:42 Анемия модели
21:59 Repositury
25:10 Domain Services Interfaces
26:15 Infrastucture Layer
30:47 DTO
31:58 Application
34:52 DDD
Презентация доклада: fwdays.com/en/...
Facebook: / fwdays
Twitter: / fwdays

[@igreezly]

Дмитрий, спасибо! Очень доступно, ёмко, содержательно, с примерами и без воды. Лучшее выступление по теме DDD!

[@ЕвгенийАлексеенко-д4щ]

Согласен

[@88billizzard88]

Это просто гениально, очень классно, просто все по полочкам

[@amirjaminov9353]

Я думаю этот доклад надо рекомендовать всем, кто начинает знакомиться с ДДД. Прям максимально просто и ничего лишнего

[@амфибий]

Единственный толковый доклад по DDD во всей трубе

[@follower90]

Доклад отличный. Уже с десяток пересмотрел по данной теме. Этот прямо вдохновил и открыл глаза на некоторые детали. Заслуженный лайк и положительный отзыв. Спасибо!

[@nameless_bro1]

Сказочно! Обо всем рассказал доступно и понятно с качественными примерами кода и абстракций. Большое спасибо конференции и ведущему!

[@Someniatko]

Потрясающий доклад. Давно пытался познакомиться с DDD, но никак всё не связывалось в единую целостную картину. Послушав же Диму, как будто в голове что-то соединилось, и стало кристалльно прозрачным. Особенный респект за объяснение аггрегатов!

[@makkapoya]

Отличный доклад! Спасибо за труд

[@ДмитрийПоздняков-щ6ь]

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

[@OlegSkalozub]

Спасибо за хороший доклад, развивайте свой канал, расскрывайте эту тему больше, у Вас хорошо получается

[@alexaverkiyev9099]

очень круто рассказал! Актуально в конце 2021 !!!

[@vesh95]

Да. yii2 дает нам модели, которые легко заполняются даже самыми глубоко вложенными данными, и не хило так умеют валидировать. Тогда получается, что object-value отпадает? А с инфраструктурного уровня легко можно возвращать объекты класса Model? Казалось бы у нас зависимость от фреймворка высовывается, но тут и Sql*Repository в первую очередь мы бы начали реализовывать через фреймворковский Activerecord, а даже если не через него, то в примере описан пример с db-connection от Yii2 (хэлп плиз, шо за?)

[@websoda]

кайф, спасибо

[@maxyc.webber]

Доклад хороший. но есть вопросы. AddressDto::fromRequest как бы намекает нам о том, что этот дто должен находиться в слое инфраструктуры, но если он будет в инфраструктуре, то я не имею права прокидывать его в аппликейшен, ибо нарушу направление зависимости. Про аппликейшен было сильно в скольз упомянуто. Я понял так, что это просто прослойка между инфраструктурой и доменом. Но мне показалось что это основной бизнес слой. здесь описывается поведение программы, используя данные из инфраструктуры и домен для обработки

[@maxyc.webber]

наверное следом тот же самый вопрос про диспетчеризацию событий. я из аппликейшена вызываю диспетчер из инфраструктуры. кажется это не верно

[@alexanderkozlikhin]

Хороший доклад!Но вот опять, почему все постоянно цену называют стоимостью? А ведь на слайде правильно написано "price: float", при чем тут стоимость?

[@OloloStalin]

Спасибо за доклад. Тема интересная и расписана довольно понятно. Особый плюс докладчику за подачу и дикцию - умеет выступать. Так держать! ПС: Уважаемый автор, а есть ли у вас еще доклады по другим темам? Было бы интересно ознакомиться

[@alexkazimir3835]

Дмитрий, молодец, приятно и понятно слушать

[@ruslanalimbetov376]

Буду локаничным) Круто и достпуно

[@balkrash]

В чем отличие этих двух книг: Domain-Driven Design: Tackling Complexity in the Heart of Software Domain-Driven Design Reference: Definitions and Pattern Summaries? Второй что то типа справочника? И почему нет книги Вернона в рекомендациях?

[@S1lverFire]

Да, вторая - это конспект первой для быстрого ознакомления. На том же слайде, где рекомендации Эванса, есть ссылка на GitHub. Там в репозитории state-of-the-union есть блок "Recommended reading", где кроме Вернона есть еще много чтива :)

[@andreyklochok]

Отличный доклад, спасибо!

[@NofaceAndrew]

Здорово конечно, но контексты в DDD это прям очень важно, нельзя рассуждать о моделях, без контекста в котором они работают, иначе это просто превращается в rich domain model. В разных контекстах может даже отличаться единый язык (иметь разные диалекты), разные классы описывающие одну и ту де модель, с разным поведением и по-разному отображающиеся в БД.

[@АлександрКубит]

Вопрос только один, как это он так хитро объявил dto объект на инфраструктурном слое, если интерфейс сервиса объявлен на уровне домена, это значит что и о dto объекте должно быть известно на уровне домена.

[@S1lverFire]

Упущение, однако ¯\_(ツ)_/¯ Спасибо, что обратили внимание)

[@ejoys3]

@@S1lverFire было б круто где-нить глянуть более полный код данного примера для понимания всех архитектурных нюансов. Доклад огонь.

[@x0r1k]

Никто не мешает DTO создать на нижнем уровне, например: class User { function update(UserUpdateDTO $dto) { ... } }

[@andreykulikovsky817]

Отличный доклад, но почему нет упоминания про DataMapper, UoW (та же доктрина) для инфраструктурного слоя.

[@S1lverFire]

Спасибо. Ограничение во времени не даёт возможности раскрыть больше концепций.

[@karafunarmenian6312]

Здравствуйте спасибо за урок Дмитрий . Такая ситуация у меня. есть юзер и у каждого юзера много счетов. + к этому ничего не привязан к юзеру. тогда юзер энтити или агрегат ? то есть хочу уточнить - должна ли в программе минимум 1 агрегат быть(если не явный тогда энтити берем вместо агрегата). спасибо заранее .

[@S1lverFire]

Здравствуйте. Если у Юзера есть много Счетов то все Счета должны ссылаться на одного и того же Юзера. Поскольку энтити уникален только в пределах агрегата, то для реализации требования из предыдущего предложения, нужно чтобы Юзер был уникален глобально в системе, тогда он становится Aggregate Root'ом. А вообще у вас скорее всего есть путаница с границами или языком домена. Словом Юзер обычно называют пользователя приложения, который аутентифицирован, а контексте Счетов уместнее говорить о Покупателе, Клиенте или Контрагенте.

[@karafunarmenian6312]

@@S1lverFire то есть менять юзер на клиент ? и с агрегатом делать тоже самое ?

[@karafunarmenian6312]

@@S1lverFire " Если у Юзера есть много Счетов то все Счета должны ссылаться на одного и того же Юзера. " - Я имел ввиду кроме счетов ничего не привязан

[@S1lverFire]

KaraFun Armenian почитайте про Bounded context. В приложении может быть и Юзер и Клиент, но в разных контекстах они будут иметь разное значение.

[@karafunarmenian6312]

@@S1lverFire ок. спасибо за советы )

[@mirlaniusUMK]

очень круто, спасибо за подачу

[@HEX_CAT]

❤❤❤

[@ВладимирБ-щ5д]

Очень круто, понятно и забавно в конце =)

[@c00p3rok]

ах-ах!! сердце!! врача!!! Итем!..

[@svetatam]

Просто о сложном :) чет не просто :)

[@balkrash]

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

[@S1lverFire]

Есть две крайности: стараться получить максимально анемичную модель, разложив всю логику по сервисам; и стараться всеми силами не допустить анемичной модели, избегая создания сервисов. У обоих подходов есть свои евангелисты. Вы можете выбрать любую из крайностей или остановиться посередине - смотря что больше подходит для проекта. Изобретать хрень вам не нужно, её уже давно изобрели, и да, если вам не нужен паттерн State Machine - просто не используйте его ;)

[@balkrash]

Спасибо за ответ!

[@scheidegg]

Спасибо. Пилите еще.

[@davidkarapetyan9904]

Дмитрий здравствтуйте, можно ли иметь Value object который не зависим ?например курс доллара в евро

[@S1lverFire]

Добрый день, Давид. Не уверен, что правильно понял ваш вопрос. Можете попробовать перефразировать его, пожалуйста?)

[@bobslave7063]

Спасибо, отличный доклад.

[@dmitryocheretko703]

Спасибо. Крайне полезно

[@EshkinKot1980]

Смотрел доклад и мучился вопросом, что докладчик делает среди Yii-шников. Какое вообще DDD имеет отношение к Yii, ведь Yii это, скорее, про блоги с котиками а не про enterprise. Доклад хороший, жаль только, что короткий. Однозначно лайк. Очень хотелось бы найти ролики, в которых тема DDD полностью раскрыта и нет отговорок, что вот этот кусочек, это тема отдельного доклада. Но что-то они не ищутся. Видимо все же придется прочитать эти здоровенные книги(

[@S1lverFire]

Спасибо за отзыв. В один доклад без оговорок впихнуть весь DDD не получится. Посмотрите канал DDD Europe - у них там пару суток контента

[@IlyaPermyakov]

Напутано - Appication Service подается как Domain Service. ClientService это Application но никак не Domain.

[@Ya-GalinaVyacheslavovna]

Годный доклад, но мозги плавит немного )) ну, патамушта ООП-дизайн всегда это делает)))

[@РоманСафин-т9ю]

Думал что все неплохо в докладе, пока речь не пошла о трейтах

[@S1lverFire]

Почему нет? Как бы сделали вы? Трейт - неплохой способ получить стандартную реализацию без создания древа наследования и без явной композиции, которая потребует инициализации других объектов. В Kotlin есть прикольная возможность - называется Delegate class, но в PHP такого инструмента нет.

[@mikeshapovalov2459]

​@@S1lverFire трейт создает жесткую зависимость домена от инфраструктуры, в большинстве случаев это допустимый компромисс, но в идеальном случае вместо трейта в агрегат нужно внедрить зависимость которая будет имплементировать интерфейс отправки событий объявленный доменом.

[@5821262]

супер

[@ВиталийПугач-к8ю]

Спасибо

[@AndriiKuftachov]

А в чем проблема с валидацией? Каждый слой делает свою валидацию. Доклад классный, но опять впечатление, что на конференциях по PHP рассказывают то, что в Java уже Junior должен знать.

[@ThisDaveAndThatJohn]

1. PHP не Java 2. В Java ничего не заработает, хоть один класс-да должен быть, поэтому не стоит удивляться что джависты продвинутей в ООП.

[@Morrado]

Спорный это вопрос, имхо. Когда в Java юзали EJB (и пухли с него), я не понимал, почему нельзя нормальный фреймворк запилить. В PHP и в C# уже юзались во всю MVC фреймворки, была интуитивно понятная архитектура. Spring MVC убил EJB(что радует), но ведь так писать можно было и без Spring. Про DDD же много говорят последние несколько лет, но юзает его в Java даже не половина(а книге Эванса уже 15 лет испольнилось). Пэпхэпэшники в этом плане молодцы, и ООП уже у них на одном из первых мест и подходы всякие внедряют быстро. IoC контейнер уже даже есть(для меня это новость). По поводу джунов, как по мне - джун должен знать сам язык, ООП, массивы, структуры данных, алгоритмы, возможно паттерны и ещё по-мелочи. А подходы, архитектурные решения, технологии и т.д. - это все в качестве плюсов. Если конечно компания не планирует собрать команду из одних джунов, чтоб они запилили крутой продукт со старта за пару месяцев.

[@MrFrimko]

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

[@rusrb]

сначала кажется что жирно, но когда проект вырастет, будет не жирнее и менее запутанно кучи вермишелевого кода (все по полкам)

[@ИльяСмирнов-л4ц]

А чем это отличается от kzbin.info/www/bejne/qJvXk3avlsh9l9U ?

[@РоманСохарев-ю2ф]

Драйвн, драйвн, плеать )

[@S1lverFire]

Не-а :) dictionary.cambridge.org/ru/словарь/английский/driven

[@РоманСохарев-ю2ф]

ох-ть. Тот самый момент, когда всю жизнь думал, что спрайт зелёный.

[@ICSVortex-DCS]

Бесполезное видео как по мне. Ничего не понял.

[@SVDDEN]

Дривен)))0

[@ThisDaveAndThatJohn]

ну так и правильно