0. ни слова о том, зачем ДДД. 1. схема с ддд в описании архитектур не верная. Репозиторий ни когда не знает ничего о вьюхах. А на схеме - знает и много. 2. Энтити отличается от value-object тем что имеет уникальный идентификатор для каждого экземпляра и обычно экземпляры мутабельны. 3. сила интерфейсов к репозиториям в том, что реализация этих репозиториев может быть разной, под разные хранилища. При этом доменной модели на это плевать. 4. ни слова не сказано про DTO. А ведь именно они пробрасываются между слоями. 5. Salary не может быть value-object. Оклад - может, зарплата - нет. Поскольку зарплата включает в себя штрафы, надбавки и т.п. И вполне себе может иметь айди.
"ни слова о том, зачем ДДД." - никто из адептов этой over engineered дичи так и не смог объяснить, зачем оно нужно для бекенда сайта на PHP, когда весь смысл бекенда: получить запрос, достать данные из базы, отдать данные обратно и... забыть про все, что было сделано до следующего раза. Складывается такое впечатление, что у программистов какой-то лютый комплекс неполноценности. Ввиду отсутствия чего-либо фундаментального в высокоуровневом программировании, они стремятся нагородить всякой дичи, чтобы их работа выглядела более внушительно. С точки зрения реальных инженеров (т.е. не софтовых) это же просто преступление: (условно) вместо 3-х строительных блоков использовать 5, обернув их какой-нибудь "прогрессивной" пленкой, чтобы ценник распух, ну и потом это все каждый год будет дополнительного контроля на тему "не оплавилась ли пленка летом", что удорожает еще и эксплуатацию сооружения.
Тема очень не простая. Спасибо за труды конечно, но по-моему только больше запутал зрителей. Про выгоду репозиториев при runtime это что за мысль? не понятно что хотел сказать. Про единый язык, без примеров кода, не ясно для чего этот зверь вообще. Концепция DDD включает три столпа Агрегаты-Сущности-ОбъектыЗначения. Про агрегаты в видео не слова. Делаю вывод вы (автор) даже бегло с концепцией не разобрались. Про репозитории тоже всё скомкано получилось. Любой интерфейс описывает поведение, если мы его имплементируем(реализуем) значит подписываем "контракт", что от нашего объекта можно ждать соответствующего поведения. А объект не обязательно работает с базой данных, это может быть CLI, Rabbit и т.д. Но как говориться критикуешь предлагай: 1. Удалить этот ролик. 2. Записать ролик про концепцию DDD с короткими примерами кода (3-4 строки) 3. Записать ещё ролик (можно не один) про практическое применение DDD в границах фреймворка Laravel. Ещё в DDD не может быть всё свалено в одну папку src (тогда это не DDD), поскольку есть такое понятие как border context.
Почему принято в корне создавать папки controllers, resourses и тд. Ведь удобнее если бы на верхнем уровне были модули, вроде users, а внутри уже контроллеры ресурсы и тд юзера. Тогда, работая с юзерами не придется искать его классы по всему проекту, а все будет рядом. И так же с классами DDD.
а если у человека фамилия поменяется, а нужно распечатать в старом документе старую фамилию? а если работник уволился, а потом снова устроился? а если полные тезки будут то одно велью будет или два одинаковых? - так это бред?
Привет, часто твои видосы спасают, сделай пожалуйста на nuxt js + laravel гайд с деплоем на сервер , классика laravel mysql + nuxt js для SSR пожалуйста)
Автор привет. Мне очень интересно увидить ролик на тему бек офиса и создания контент элементов. Их администрирование, заполнение и так далее. Я понимаю как это работает в cms но не на Laravel.
Было б здорово показать распаковку сути DDD в виде многошагового развития какой-то базовой рабочей версии чего-либо, да тех же воркеров.. типа вот наш концепт, а теперь давайте усложним задачу несколько раз вот так, дабы ощущить всю мощь -тёмной стороны силы- DDD, #ящетаю...
👍🏻 спасибо, ддд как будто какой-то порог, если его прошел и можешь объяснить что к чему то норм и даже не обязательно действительно уметь применять. Надеюсь на продолжение по асинхронности, cqrs, rabbit)
если речь про бизнес логику то да. А если про логику поведения объекта то что-то лучше добавить в методы объекта. На пример, сущность Квартира, у неё есть общая площадь, которая вычисляется на основе суммы площадей входящих в неё помещений. А вот если нужно применить какой либо коэффициент то лучше вызвать этот метод где-то в методе сервиса, и в случае изменения коэффициента или ещё чего, добавить дополнительный метод.
Здравствуйте, посмотрел много ваших видео и хотел спросить, если посмотреть все ваши платные курсы по ларавел, можно ли уверенно идти на работу на позицию jun?
Реестр сотрудников не является адекватным примером предметной области. Для такого приложения не нужно даже городить никакое DDD. Достаточно интерфейса к базе данных с некоторыми проверками. Предметной областью может быть вся фирма, если там действительно есть сложная бизнес-логика. Иначе достаточно CRUD приложения. Сущность не является предметной областью. Короче, слышал звон да не знаю где он, из DDD тут только набор непонятых автором терминов.
никто никогда при разговоре про DDD не говорит ЗАЧЕМ и КАК с этим потом работать? опять одна вода и 0 путных мыслей, сколько раз еще такие ролики будут иметь место? нахрена к ларавелю это всё прикручивать и изобретать велосипед? как их между собой вязать, если в ларе модели друг к другу вяжутся нормально, как объекты в БД со связами через внешние ключи, то здесь всё, приехали ваши вэлью обжекты существубт сами по себе, как их коннектить друг к другу непонятно, вы проигрываете в скорости, во всём, все сущности у вас теперь атомарны, ни о каких джойнах теперь речи не идёт, вы просто всё разделили, запросов в БД больше, удобства меньше зачем здесь DTO если у вас уже и там ValueObject? хоспади, есть ощущение что вы вообще не понимаете что вы делаете и для чего, это какие-то понты без обоснования, типа смотри как могу никто не отвечает на эти вопросы, загадка остаётся нерешённой
++. Как опытный велосипедист, всегда вижу когда педали не в ту сторону крутятся. Нужен адаптированный ДДД под прекрасные модели ларавел, может быть не очень правильный но всё же.
Да просто Laravel, так же как и Yii(оба), заточен под Active Record, что соотвествует подходу Database First. Естественно, прикручивание этой дичи (DDD) всегда будет выглядеть, как пришивание второго хвоста и пятй ноги собаке. Было бы понятно, если бы эти любители over engineering-а создавали бы своих моностров БЕЗ фреймворков, но нет...
Вы лучший блогер по Ларавел 🎉🎉🎉
Ролик отличный!
Огромное спасибо за ваш труд. Очень крутой материал
Благодарю!:)
0. ни слова о том, зачем ДДД.
1. схема с ддд в описании архитектур не верная. Репозиторий ни когда не знает ничего о вьюхах. А на схеме - знает и много.
2. Энтити отличается от value-object тем что имеет уникальный идентификатор для каждого экземпляра и обычно экземпляры мутабельны.
3. сила интерфейсов к репозиториям в том, что реализация этих репозиториев может быть разной, под разные хранилища. При этом доменной модели на это плевать.
4. ни слова не сказано про DTO. А ведь именно они пробрасываются между слоями.
5. Salary не может быть value-object. Оклад - может, зарплата - нет. Поскольку зарплата включает в себя штрафы, надбавки и т.п. И вполне себе может иметь айди.
"ни слова о том, зачем ДДД." - никто из адептов этой over engineered дичи так и не смог объяснить, зачем оно нужно для бекенда сайта на PHP, когда весь смысл бекенда: получить запрос, достать данные из базы, отдать данные обратно и... забыть про все, что было сделано до следующего раза.
Складывается такое впечатление, что у программистов какой-то лютый комплекс неполноценности. Ввиду отсутствия чего-либо фундаментального в высокоуровневом программировании, они стремятся нагородить всякой дичи, чтобы их работа выглядела более внушительно.
С точки зрения реальных инженеров (т.е. не софтовых) это же просто преступление: (условно) вместо 3-х строительных блоков использовать 5, обернув их какой-нибудь "прогрессивной" пленкой, чтобы ценник распух, ну и потом это все каждый год будет дополнительного контроля на тему "не оплавилась ли пленка летом", что удорожает еще и эксплуатацию сооружения.
Тема очень не простая. Спасибо за труды конечно, но по-моему только больше запутал зрителей. Про выгоду репозиториев при runtime это что за мысль? не понятно что хотел сказать. Про единый язык, без примеров кода, не ясно для чего этот зверь вообще. Концепция DDD включает три столпа Агрегаты-Сущности-ОбъектыЗначения. Про агрегаты в видео не слова. Делаю вывод вы (автор) даже бегло с концепцией не разобрались. Про репозитории тоже всё скомкано получилось. Любой интерфейс описывает поведение, если мы его имплементируем(реализуем) значит подписываем "контракт", что от нашего объекта можно ждать соответствующего поведения. А объект не обязательно работает с базой данных, это может быть CLI, Rabbit и т.д. Но как говориться критикуешь предлагай: 1. Удалить этот ролик. 2. Записать ролик про концепцию DDD с короткими примерами кода (3-4 строки) 3. Записать ещё ролик (можно не один) про практическое применение DDD в границах фреймворка Laravel. Ещё в DDD не может быть всё свалено в одну папку src (тогда это не DDD), поскольку есть такое понятие как border context.
Можно видео-обзор для jetstream?
пожалуйста, сделайте 1 задание поменьше, используя DDD внутри laravel
Куда пропал ?
Спасибо, автору за новое видео, один из лучших блогеров по веб-разработке) при том что еще и ролики очень полезные и на актуальные темы!
Благодарю!:)
Почему принято в корне создавать папки controllers, resourses и тд. Ведь удобнее если бы на верхнем уровне были модули, вроде users, а внутри уже контроллеры ресурсы и тд юзера. Тогда, работая с юзерами не придется искать его классы по всему проекту, а все будет рядом. И так же с классами DDD.
Огромное спасибо автору за данное видео! Было бы здорово увидеть написание проекта на laravel с использованием DDD.
Спасибо тебе братан! Как всегда, видео на высоте. Единственный релевантный блогер по Laravel. Не бросай своё дело!
Благодарю!:)
Тема DDD не раскрыта
а если у человека фамилия поменяется, а нужно распечатать в старом документе старую фамилию? а если работник уволился, а потом снова устроился? а если полные тезки будут то одно велью будет или два одинаковых? - так это бред?
Привет, часто твои видосы спасают, сделай пожалуйста на nuxt js + laravel гайд с деплоем на сервер , классика laravel mysql + nuxt js для SSR пожалуйста)
Автор привет. Мне очень интересно увидить ролик на тему бек офиса и создания контент элементов. Их администрирование, заполнение и так далее. Я понимаю как это работает в cms но не на Laravel.
Для меня проблема это как правилньо архитектуру создавать.
Когда в одиночку кодишь, но хочется красиво и понятно.
Спасибо за урок
Здарова! Не останавливайся! Всё будет! Спасибо!
Спасибо автору. Но почему репозиторий описан в доменном слое. Разве домен не обязан быть в неведении относительно репозиториев?
Когда использовать DDD вместо MVC?
Было б здорово показать распаковку сути DDD в виде многошагового развития какой-то базовой рабочей версии чего-либо, да тех же воркеров.. типа вот наш концепт, а теперь давайте усложним задачу несколько раз вот так, дабы ощущить всю мощь -тёмной стороны силы- DDD, #ящетаю...
preg_match разве не будет ексепшны выдавать? Там надо ! вроде как поставить. Иначе на киррилицу будет эксепшны выдавать.
В классе Name.
Это пример, там много чего можно сделать:)
В ObjectValue выбрасывается http exception. Так не хорошо делать, перепрыгивая целый слой
🙏👍❗
расскажешь про постмен и подводные камни?
👍🏻 спасибо, ддд как будто какой-то порог, если его прошел и можешь объяснить что к чему то норм и даже не обязательно действительно уметь применять.
Надеюсь на продолжение по асинхронности, cqrs, rabbit)
Да, согласен по реббиту надо больше) cqrs тоже было бы не плохо.
Благодарю!:) Посмотрим:)
@@Евгений-т3ц9к что такое cqrs?
@@biLLie_wiLLieCommand Query Responsibility Segregation
о нормас давай еще
Благодарю!:)
Ого спасибо! Стало понятнее про ДДД 👍 а про тестирование будут ролики? а то на многих собесах спрашивают про это.
ua-cam.com/video/leaXsWyfQRs/v-deo.html&ab_channel=LaravelCreative
Азиз, спасибо большое, как всегда, все четко и актуально!!!
Спасибо! Очень понятно преподнёс! 😊
Большое спасибо за видео, очень позеавательно
расскажи как документацию проекта делать
Благодарю!:)
А где у вас на канале раньше были видео по тестам? Вы их закрыли, что ли? Юнит тесты и ещё, кажется, какие-то были.
Здравствуйте! Вот бы еще ролик как это все запустить. Те же например банальные CRUDы. Спасибо большое.
тоесть лучше логику в сервисы пихать ?
Ну вообще от ситуации, если логика какая то сложная, ты можешь ее вынести в доменный слой приложения, так Адель писал☝️. От случая зависит
если речь про бизнес логику то да. А если про логику поведения объекта то что-то лучше добавить в методы объекта. На пример, сущность Квартира, у неё есть общая площадь, которая вычисляется на основе суммы площадей входящих в неё помещений. А вот если нужно применить какой либо коэффициент то лучше вызвать этот метод где-то в методе сервиса, и в случае изменения коэффициента или ещё чего, добавить дополнительный метод.
@@hotis8 а в чем разница от бизнес логики я не понял
@@artemunix5223 коротко для себя это сформулировал так - в объекте только та логика которая от бизнес-процессов не зависит.
Может к этому видео не относится, но как на счёт урока про репликацию, master-slave в laravel для Mysql
Есть же канонический перевод - "Предметно-ориентированный дизайн". Гораздо точнее отражает суть, чем "на основе".
Условие в методе assertSalaryIsValid должно быть противоположным
Здравствуйте, посмотрел много ваших видео и хотел спросить, если посмотреть все ваши платные курсы по ларавел, можно ли уверенно идти на работу на позицию jun?
Более чем
Большое спасибо
Благодарю!:)
Автор, спасибо тебе!
Благодарю!:)
пожалуйста это было очень нужно
Имя можно разделить на first name и last name)
оно в коде так и реализованно
Очень понятно разложил!
Благодарю!:)
Благодарю!!! 🤝
Благодарю!:)
Стоит использовать phpmyadmin?
Здравствуйте, интересует вопрос, а не хотели бы Вы, или, возможно, у Вас есть в планах, начать рассказывать про Symfony?
Реестр сотрудников не является адекватным примером предметной области. Для такого приложения не нужно даже городить никакое DDD.
Достаточно интерфейса к базе данных с некоторыми проверками.
Предметной областью может быть вся фирма, если там действительно есть сложная бизнес-логика. Иначе достаточно CRUD приложения.
Сущность не является предметной областью.
Короче, слышал звон да не знаю где он, из DDD тут только набор непонятых автором терминов.
никто никогда при разговоре про DDD не говорит ЗАЧЕМ и КАК с этим потом работать?
опять одна вода и 0 путных мыслей, сколько раз еще такие ролики будут иметь место?
нахрена к ларавелю это всё прикручивать и изобретать велосипед?
как их между собой вязать, если в ларе модели друг к другу вяжутся нормально, как объекты в БД со связами через внешние ключи, то здесь всё, приехали ваши вэлью обжекты существубт сами по себе, как их коннектить друг к другу непонятно, вы проигрываете в скорости, во всём, все сущности у вас теперь атомарны, ни о каких джойнах теперь речи не идёт, вы просто всё разделили, запросов в БД больше, удобства меньше
зачем здесь DTO если у вас уже и там ValueObject? хоспади, есть ощущение что вы вообще не понимаете что вы делаете и для чего, это какие-то понты без обоснования, типа смотри как могу
никто не отвечает на эти вопросы, загадка остаётся нерешённой
ладно, в конце вроде нормально раскрыл, забираю свои выебоны обратно
++. Как опытный велосипедист, всегда вижу когда педали не в ту сторону крутятся. Нужен адаптированный ДДД под прекрасные модели ларавел, может быть не очень правильный но всё же.
@@zxc7613 фреймворки для того, чтобы бить по рукам, но когда на уже существующие пытаются наслоить что-то еще своё, я бы пиздил еще и ногами
@@litvinenkow ахахахха
Да просто Laravel, так же как и Yii(оба), заточен под Active Record, что соотвествует подходу Database First. Естественно, прикручивание этой дичи (DDD) всегда будет выглядеть, как пришивание второго хвоста и пятй ноги собаке. Было бы понятно, если бы эти любители over engineering-а создавали бы своих моностров БЕЗ фреймворков, но нет...