Просто о сложном - Domain Driven Design [ru] / Дмитрий Науменко
HTML-код
- Опубликовано: 28 сен 2024
- Конференция 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
Дмитрий, спасибо!
Очень доступно, ёмко, содержательно, с примерами и без воды. Лучшее выступление по теме DDD!
Согласен
Это просто гениально, очень классно, просто все по полочкам
Доклад отличный. Уже с десяток пересмотрел по данной теме. Этот прямо вдохновил и открыл глаза на некоторые детали. Заслуженный лайк и положительный отзыв. Спасибо!
Сказочно! Обо всем рассказал доступно и понятно с качественными примерами кода и абстракций. Большое спасибо конференции и ведущему!
Спасибо за хороший доклад, развивайте свой канал, расскрывайте эту тему больше, у Вас хорошо получается
Единственный толковый доклад по DDD во всей трубе
кайф, спасибо
Спасибо за доклад. Тема интересная и расписана довольно понятно. Особый плюс докладчику за подачу и дикцию - умеет выступать. Так держать!
ПС: Уважаемый автор, а есть ли у вас еще доклады по другим темам? Было бы интересно ознакомиться
Да. yii2 дает нам модели, которые легко заполняются даже самыми глубоко вложенными данными, и не хило так умеют валидировать. Тогда получается, что object-value отпадает? А с инфраструктурного уровня легко можно возвращать объекты класса Model? Казалось бы у нас зависимость от фреймворка высовывается, но тут и Sql*Repository в первую очередь мы бы начали реализовывать через фреймворковский Activerecord, а даже если не через него, то в примере описан пример с db-connection от Yii2 (хэлп плиз, шо за?)
Доклад хороший. но есть вопросы.
AddressDto::fromRequest как бы намекает нам о том, что этот дто должен находиться в слое инфраструктуры, но если он будет в инфраструктуре, то я не имею права прокидывать его в аппликейшен, ибо нарушу направление зависимости.
Про аппликейшен было сильно в скольз упомянуто. Я понял так, что это просто прослойка между инфраструктурой и доменом. Но мне показалось что это основной бизнес слой. здесь описывается поведение программы, используя данные из инфраструктуры и домен для обработки
наверное следом тот же самый вопрос про диспетчеризацию событий. я из аппликейшена вызываю диспетчер из инфраструктуры. кажется это не верно
В чем отличие этих двух книг:
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", где кроме Вернона есть еще много чтива :)
Дмитрий, молодец, приятно и понятно слушать
Хороший доклад, с хорошей демонстрацией сказанного. Складывается образ и целостная картина.
Хороший доклад!Но вот опять, почему все постоянно цену называют стоимостью? А ведь на слайде правильно написано "price: float", при чем тут стоимость?
Вопрос только один, как это он так хитро объявил dto объект на инфраструктурном слое, если интерфейс сервиса объявлен на уровне домена, это значит что и о dto объекте должно быть известно на уровне домена.
Упущение, однако ¯\_(ツ)_/¯
Спасибо, что обратили внимание)
@@S1lverFire было б круто где-нить глянуть более полный код данного примера для понимания всех архитектурных нюансов. Доклад огонь.
Никто не мешает DTO создать на нижнем уровне, например:
class User {
function update(UserUpdateDTO $dto) { ... }
}
ах-ах!! сердце!! врача!!! Итем!..
Здорово конечно, но контексты в DDD это прям очень важно, нельзя рассуждать о моделях, без контекста в котором они работают, иначе это просто превращается в rich domain model. В разных контекстах может даже отличаться единый язык (иметь разные диалекты), разные классы описывающие одну и ту де модель, с разным поведением и по-разному отображающиеся в БД.
Да и про анемичную модель ничего непонятно. Т.е., чтобы она не была анемичной, нужно всякую хрень изобретать? Может мне не нужен паттерн состояния?
Есть две крайности: стараться получить максимально анемичную модель, разложив всю логику по сервисам; и стараться всеми силами не допустить анемичной модели, избегая создания сервисов. У обоих подходов есть свои евангелисты. Вы можете выбрать любую из крайностей или остановиться посередине - смотря что больше подходит для проекта.
Изобретать хрень вам не нужно, её уже давно изобрели, и да, если вам не нужен паттерн State Machine - просто не используйте его ;)
Спасибо за ответ!
Просто о сложном :) чет не просто :)
Спасибо, отличный доклад.
Спасибо. Пилите еще.
Смотрел доклад и мучился вопросом, что докладчик делает среди Yii-шников. Какое вообще DDD имеет отношение к Yii, ведь Yii это, скорее, про блоги с котиками а не про enterprise.
Доклад хороший, жаль только, что короткий. Однозначно лайк. Очень хотелось бы найти ролики, в которых тема DDD полностью раскрыта и нет отговорок, что вот этот кусочек, это тема отдельного доклада. Но что-то они не ищутся. Видимо все же придется прочитать эти здоровенные книги(
Спасибо за отзыв. В один доклад без оговорок впихнуть весь DDD не получится. Посмотрите канал DDD Europe - у них там пару суток контента
Напутано - Appication Service подается как Domain Service. ClientService это Application но никак не Domain.
Думал что все неплохо в докладе, пока речь не пошла о трейтах
Почему нет? Как бы сделали вы?
Трейт - неплохой способ получить стандартную реализацию без создания древа наследования и без явной композиции, которая потребует инициализации других объектов. В Kotlin есть прикольная возможность - называется Delegate class, но в PHP такого инструмента нет.
@@S1lverFire трейт создает жесткую зависимость домена от инфраструктуры, в большинстве случаев это допустимый компромисс, но в идеальном случае вместо трейта в агрегат нужно внедрить зависимость которая будет имплементировать интерфейс отправки событий объявленный доменом.
А в чем проблема с валидацией?
Каждый слой делает свою валидацию.
Доклад классный, но опять впечатление, что на конференциях по 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
ну так и правильно
Отличный доклад! Спасибо за труд
Потрясающий доклад. Давно пытался познакомиться с DDD, но никак всё не связывалось в единую целостную картину. Послушав же Диму, как будто в голове что-то соединилось, и стало кристалльно прозрачным. Особенный респект за объяснение аггрегатов!
Я думаю этот доклад надо рекомендовать всем, кто начинает знакомиться с ДДД. Прям максимально просто и ничего лишнего
Годный доклад, но мозги плавит немного )) ну, патамушта ООП-дизайн всегда это делает)))
отличный доклад. Все по полочкам. Отличительная черта умного человека - умение обьяснить сложные вещи, так, чтобы было понятно всем.
очень круто рассказал!
Актуально в конце 2021 !!!
Буду локаничным) Круто и достпуно
Отличный доклад, но почему нет упоминания про DataMapper, UoW (та же доктрина) для инфраструктурного слоя.
Спасибо. Ограничение во времени не даёт возможности раскрыть больше концепций.
❤❤❤
Здравствуйте спасибо за урок Дмитрий . Такая ситуация у меня. есть юзер и у каждого юзера много счетов. + к этому ничего не привязан к юзеру. тогда юзер энтити или агрегат ? то есть хочу уточнить - должна ли в программе минимум 1 агрегат быть(если не явный тогда энтити берем вместо агрегата). спасибо заранее .
Здравствуйте. Если у Юзера есть много Счетов то все Счета должны ссылаться на одного и того же Юзера. Поскольку энтити уникален только в пределах агрегата, то для реализации требования из предыдущего предложения, нужно чтобы Юзер был уникален глобально в системе, тогда он становится Aggregate Root'ом. А вообще у вас скорее всего есть путаница с границами или языком домена. Словом Юзер обычно называют пользователя приложения, который аутентифицирован, а контексте Счетов уместнее говорить о Покупателе, Клиенте или Контрагенте.
@@S1lverFire то есть менять юзер на клиент ? и с агрегатом делать тоже самое ?
@@S1lverFire " Если у Юзера есть много Счетов то все Счета должны ссылаться на одного и того же Юзера. " - Я имел ввиду кроме счетов ничего не привязан
KaraFun Armenian почитайте про Bounded context. В приложении может быть и Юзер и Клиент, но в разных контекстах они будут иметь разное значение.
@@S1lverFire ок. спасибо за советы )
Отличный доклад, спасибо!
очень круто, спасибо за подачу
А чем это отличается от ruclips.net/video/rjtbCyacJas/видео.html ?
Очень круто, понятно и забавно в конце =)
супер
Дмитрий здравствтуйте, можно ли иметь Value object который не зависим ?например курс доллара в евро
Добрый день, Давид. Не уверен, что правильно понял ваш вопрос. Можете попробовать перефразировать его, пожалуйста?)
Спасибо. Крайне полезно
Спасибо
такие бы штуки писать на джаве/шарпе
писать лишние классы что бы передавать параметры на пхп, если проект большой то чет жирно получится
сначала кажется что жирно, но когда проект вырастет, будет не жирнее и менее запутанно кучи вермишелевого кода (все по полкам)