ฝัง
- เผยแพร่เมื่อ 15 มิ.ย. 2017
- Конференция 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/event/php-fwday...
Facebook: / fwdays
Twitter: / fwdays - วิทยาศาสตร์และเทคโนโลยี
![4. CS50 на русском: Лекция #4 [Гарвард, Основы программирования, осень 2015 год]](http://i.ytimg.com/vi/ej3EA451m2c/mqdefault.jpg)
Дмитрий, спасибо!
Очень доступно, ёмко, содержательно, с примерами и без воды. Лучшее выступление по теме DDD!
Согласен
Это просто гениально, очень классно, просто все по полочкам
Единственный толковый доклад по DDD во всей трубе
Доклад отличный. Уже с десяток пересмотрел по данной теме. Этот прямо вдохновил и открыл глаза на некоторые детали. Заслуженный лайк и положительный отзыв. Спасибо!
Сказочно! Обо всем рассказал доступно и понятно с качественными примерами кода и абстракций. Большое спасибо конференции и ведущему!
Я думаю этот доклад надо рекомендовать всем, кто начинает знакомиться с ДДД. Прям максимально просто и ничего лишнего
Отличный доклад! Спасибо за труд
отличный доклад. Все по полочкам. Отличительная черта умного человека - умение обьяснить сложные вещи, так, чтобы было понятно всем.
Хороший доклад, с хорошей демонстрацией сказанного. Складывается образ и целостная картина.
Потрясающий доклад. Давно пытался познакомиться с DDD, но никак всё не связывалось в единую целостную картину. Послушав же Диму, как будто в голове что-то соединилось, и стало кристалльно прозрачным. Особенный респект за объяснение аггрегатов!
очень круто рассказал!
Актуально в конце 2021 !!!
Дмитрий, молодец, приятно и понятно слушать
Отличный доклад, спасибо!
Спасибо за хороший доклад, развивайте свой канал, расскрывайте эту тему больше, у Вас хорошо получается
Буду локаничным) Круто и достпуно
очень круто, спасибо за подачу
кайф, спасибо
Спасибо, отличный доклад.
Спасибо. Пилите еще.
Очень круто, понятно и забавно в конце =)
Спасибо. Крайне полезно
Спасибо за доклад. Тема интересная и расписана довольно понятно. Особый плюс докладчику за подачу и дикцию - умеет выступать. Так держать!
ПС: Уважаемый автор, а есть ли у вас еще доклады по другим темам? Было бы интересно ознакомиться
❤❤❤
Да. yii2 дает нам модели, которые легко заполняются даже самыми глубоко вложенными данными, и не хило так умеют валидировать. Тогда получается, что object-value отпадает? А с инфраструктурного уровня легко можно возвращать объекты класса Model? Казалось бы у нас зависимость от фреймворка высовывается, но тут и Sql*Repository в первую очередь мы бы начали реализовывать через фреймворковский Activerecord, а даже если не через него, то в примере описан пример с db-connection от Yii2 (хэлп плиз, шо за?)
Просто о сложном :) чет не просто :)
ах-ах!! сердце!! врача!!! Итем!..
Отличный доклад, но почему нет упоминания про DataMapper, UoW (та же доктрина) для инфраструктурного слоя.
Спасибо. Ограничение во времени не даёт возможности раскрыть больше концепций.
В чем отличие этих двух книг:
Domain-Driven Design: Tackling Complexity in the Heart of Software
Domain-Driven Design Reference: Definitions and Pattern Summaries?
Второй что то типа справочника? И почему нет книги Вернона в рекомендациях?
Да, вторая - это конспект первой для быстрого ознакомления.
На том же слайде, где рекомендации Эванса, есть ссылка на GitHub. Там в репозитории state-of-the-union есть блок "Recommended reading", где кроме Вернона есть еще много чтива :)
Доклад хороший. но есть вопросы.
AddressDto::fromRequest как бы намекает нам о том, что этот дто должен находиться в слое инфраструктуры, но если он будет в инфраструктуре, то я не имею права прокидывать его в аппликейшен, ибо нарушу направление зависимости.
Про аппликейшен было сильно в скольз упомянуто. Я понял так, что это просто прослойка между инфраструктурой и доменом. Но мне показалось что это основной бизнес слой. здесь описывается поведение программы, используя данные из инфраструктуры и домен для обработки
наверное следом тот же самый вопрос про диспетчеризацию событий. я из аппликейшена вызываю диспетчер из инфраструктуры. кажется это не верно
Здорово конечно, но контексты в DDD это прям очень важно, нельзя рассуждать о моделях, без контекста в котором они работают, иначе это просто превращается в rich domain model. В разных контекстах может даже отличаться единый язык (иметь разные диалекты), разные классы описывающие одну и ту де модель, с разным поведением и по-разному отображающиеся в БД.
Хороший доклад!Но вот опять, почему все постоянно цену называют стоимостью? А ведь на слайде правильно написано "price: float", при чем тут стоимость?
супер
Спасибо
Напутано - Appication Service подается как Domain Service. ClientService это Application но никак не Domain.
Здравствуйте спасибо за урок Дмитрий . Такая ситуация у меня. есть юзер и у каждого юзера много счетов. + к этому ничего не привязан к юзеру. тогда юзер энтити или агрегат ? то есть хочу уточнить - должна ли в программе минимум 1 агрегат быть(если не явный тогда энтити берем вместо агрегата). спасибо заранее .
Здравствуйте. Если у Юзера есть много Счетов то все Счета должны ссылаться на одного и того же Юзера. Поскольку энтити уникален только в пределах агрегата, то для реализации требования из предыдущего предложения, нужно чтобы Юзер был уникален глобально в системе, тогда он становится Aggregate Root'ом. А вообще у вас скорее всего есть путаница с границами или языком домена. Словом Юзер обычно называют пользователя приложения, который аутентифицирован, а контексте Счетов уместнее говорить о Покупателе, Клиенте или Контрагенте.
@@S1lverFire то есть менять юзер на клиент ? и с агрегатом делать тоже самое ?
@@S1lverFire " Если у Юзера есть много Счетов то все Счета должны ссылаться на одного и того же Юзера. " - Я имел ввиду кроме счетов ничего не привязан
KaraFun Armenian почитайте про Bounded context. В приложении может быть и Юзер и Клиент, но в разных контекстах они будут иметь разное значение.
@@S1lverFire ок. спасибо за советы )
Вопрос только один, как это он так хитро объявил dto объект на инфраструктурном слое, если интерфейс сервиса объявлен на уровне домена, это значит что и о dto объекте должно быть известно на уровне домена.
Упущение, однако ¯\_(ツ)_/¯
Спасибо, что обратили внимание)
@@S1lverFire было б круто где-нить глянуть более полный код данного примера для понимания всех архитектурных нюансов. Доклад огонь.
Никто не мешает DTO создать на нижнем уровне, например:
class User {
function update(UserUpdateDTO $dto) { ... }
}
Дмитрий здравствтуйте, можно ли иметь Value object который не зависим ?например курс доллара в евро
Добрый день, Давид. Не уверен, что правильно понял ваш вопрос. Можете попробовать перефразировать его, пожалуйста?)
Да и про анемичную модель ничего непонятно. Т.е., чтобы она не была анемичной, нужно всякую хрень изобретать? Может мне не нужен паттерн состояния?
Есть две крайности: стараться получить максимально анемичную модель, разложив всю логику по сервисам; и стараться всеми силами не допустить анемичной модели, избегая создания сервисов. У обоих подходов есть свои евангелисты. Вы можете выбрать любую из крайностей или остановиться посередине - смотря что больше подходит для проекта.
Изобретать хрень вам не нужно, её уже давно изобрели, и да, если вам не нужен паттерн State Machine - просто не используйте его ;)
Спасибо за ответ!
Годный доклад, но мозги плавит немного )) ну, патамушта ООП-дизайн всегда это делает)))
такие бы штуки писать на джаве/шарпе
писать лишние классы что бы передавать параметры на пхп, если проект большой то чет жирно получится
сначала кажется что жирно, но когда проект вырастет, будет не жирнее и менее запутанно кучи вермишелевого кода (все по полкам)
А чем это отличается от th-cam.com/video/rjtbCyacJas/w-d-xo.html ?
Думал что все неплохо в докладе, пока речь не пошла о трейтах
Почему нет? Как бы сделали вы?
Трейт - неплохой способ получить стандартную реализацию без создания древа наследования и без явной композиции, которая потребует инициализации других объектов. В Kotlin есть прикольная возможность - называется Delegate class, но в PHP такого инструмента нет.
@@S1lverFire трейт создает жесткую зависимость домена от инфраструктуры, в большинстве случаев это допустимый компромисс, но в идеальном случае вместо трейта в агрегат нужно внедрить зависимость которая будет имплементировать интерфейс отправки событий объявленный доменом.
Смотрел доклад и мучился вопросом, что докладчик делает среди Yii-шников. Какое вообще DDD имеет отношение к Yii, ведь Yii это, скорее, про блоги с котиками а не про enterprise.
Доклад хороший, жаль только, что короткий. Однозначно лайк. Очень хотелось бы найти ролики, в которых тема DDD полностью раскрыта и нет отговорок, что вот этот кусочек, это тема отдельного доклада. Но что-то они не ищутся. Видимо все же придется прочитать эти здоровенные книги(
Спасибо за отзыв. В один доклад без оговорок впихнуть весь DDD не получится. Посмотрите канал DDD Europe - у них там пару суток контента
А в чем проблема с валидацией?
Каждый слой делает свою валидацию.
Доклад классный, но опять впечатление, что на конференциях по PHP рассказывают то, что в Java уже Junior должен знать.
1. PHP не Java
2. В Java ничего не заработает, хоть один класс-да должен быть, поэтому не стоит удивляться что джависты продвинутей в ООП.
Спорный это вопрос, имхо. Когда в Java юзали EJB (и пухли с него), я не понимал, почему нельзя нормальный фреймворк запилить. В PHP и в C# уже юзались во всю MVC фреймворки, была интуитивно понятная архитектура. Spring MVC убил EJB(что радует), но ведь так писать можно было и без Spring. Про DDD же много говорят последние несколько лет, но юзает его в Java даже не половина(а книге Эванса уже 15 лет испольнилось). Пэпхэпэшники в этом плане молодцы, и ООП уже у них на одном из первых мест и подходы всякие внедряют быстро. IoC контейнер уже даже есть(для меня это новость).
По поводу джунов, как по мне - джун должен знать сам язык, ООП, массивы, структуры данных, алгоритмы, возможно паттерны и ещё по-мелочи. А подходы, архитектурные решения, технологии и т.д. - это все в качестве плюсов. Если конечно компания не планирует собрать команду из одних джунов, чтоб они запилили крутой продукт со старта за пару месяцев.
Драйвн, драйвн, плеать )
Не-а :) dictionary.cambridge.org/ru/словарь/английский/driven
ох-ть. Тот самый момент, когда всю жизнь думал, что спрайт зелёный.
Дривен)))0
ну так и правильно
Бесполезное видео как по мне. Ничего не понял.