DDD архитектура база. Domain Driven Design архитектурный подход.
ฝัง
- เผยแพร่เมื่อ 20 ก.ค. 2024
- Стань спонсором(бусти аккаунт), доступ к собеседованиям:
boosty.to/laravelcreative
Мои платные курсы:
laravelcreative.ru/course
План развития с нуля до middle+:
laravelcreative.ru/other/plan
Группа вк:
laravelcreative
СОДЕРЖАНИЕ
00:00:00 Введение
00:01:44 Что такое DDD
00:05:51 Зачем нужны архитектурные подходы
00:09:13 Из чего состоит DDD, структура папок и классов
00:17:31 Структура папок и классов DDD на базовом уровне в коде
00:26:26 Еще раз последовательность, как создавать классы
00:29:43 Когда уместно использовать DDD
Огромное спасибо автору за данное видео! Было бы здорово увидеть написание проекта на laravel с использованием DDD.
Спасибо, автору за новое видео, один из лучших блогеров по веб-разработке) при том что еще и ролики очень полезные и на актуальные темы!
Благодарю!:)
Азиз, спасибо большое, как всегда, все четко и актуально!!!
Спасибо тебе братан! Как всегда, видео на высоте. Единственный релевантный блогер по Laravel. Не бросай своё дело!
Благодарю!:)
Здарова! Не останавливайся! Всё будет! Спасибо!
Спасибо! Очень понятно преподнёс! 😊
Вы лучший блогер по Ларавел 🎉🎉🎉
Ролик отличный!
Огромное спасибо за ваш труд. Очень крутой материал
Благодарю!:)
Большое спасибо за видео, очень позеавательно
Тема очень не простая. Спасибо за труды конечно, но по-моему только больше запутал зрителей. Про выгоду репозиториев при runtime это что за мысль? не понятно что хотел сказать. Про единый язык, без примеров кода, не ясно для чего этот зверь вообще. Концепция DDD включает три столпа Агрегаты-Сущности-ОбъектыЗначения. Про агрегаты в видео не слова. Делаю вывод вы (автор) даже бегло с концепцией не разобрались. Про репозитории тоже всё скомкано получилось. Любой интерфейс описывает поведение, если мы его имплементируем(реализуем) значит подписываем "контракт", что от нашего объекта можно ждать соответствующего поведения. А объект не обязательно работает с базой данных, это может быть CLI, Rabbit и т.д. Но как говориться критикуешь предлагай: 1. Удалить этот ролик. 2. Записать ролик про концепцию DDD с короткими примерами кода (3-4 строки) 3. Записать ещё ролик (можно не один) про практическое применение DDD в границах фреймворка Laravel. Ещё в DDD не может быть всё свалено в одну папку src (тогда это не DDD), поскольку есть такое понятие как border context.
Почему принято в корне создавать папки controllers, resourses и тд. Ведь удобнее если бы на верхнем уровне были модули, вроде users, а внутри уже контроллеры ресурсы и тд юзера. Тогда, работая с юзерами не придется искать его классы по всему проекту, а все будет рядом. И так же с классами DDD.
👍🏻 спасибо, ддд как будто какой-то порог, если его прошел и можешь объяснить что к чему то норм и даже не обязательно действительно уметь применять.
Надеюсь на продолжение по асинхронности, cqrs, rabbit)
Да, согласен по реббиту надо больше) cqrs тоже было бы не плохо.
Благодарю!:) Посмотрим:)
@@user-cp8ou1ot5z что такое cqrs?
@@biLLie_wiLLieCommand Query Responsibility Segregation
Очень понятно разложил!
Благодарю!:)
Автор, спасибо тебе!
Благодарю!:)
пожалуйста это было очень нужно
Было б здорово показать распаковку сути DDD в виде многошагового развития какой-то базовой рабочей версии чего-либо, да тех же воркеров.. типа вот наш концепт, а теперь давайте усложним задачу несколько раз вот так, дабы ощущить всю мощь -тёмной стороны силы- DDD, #ящетаю...
Ого спасибо! Стало понятнее про ДДД 👍 а про тестирование будут ролики? а то на многих собесах спрашивают про это.
th-cam.com/video/leaXsWyfQRs/w-d-xo.html&ab_channel=LaravelCreative
Для меня проблема это как правилньо архитектуру создавать.
Когда в одиночку кодишь, но хочется красиво и понятно.
Спасибо за урок
Здравствуйте! Вот бы еще ролик как это все запустить. Те же например банальные CRUDы. Спасибо большое.
Большое спасибо
Благодарю!:)
Благодарю!!! 🤝
Благодарю!:)
о нормас давай еще
Благодарю!:)
Привет, часто твои видосы спасают, сделай пожалуйста на nuxt js + laravel гайд с деплоем на сервер , классика laravel mysql + nuxt js для SSR пожалуйста)
расскажешь про постмен и подводные камни?
Автор привет. Мне очень интересно увидить ролик на тему бек офиса и создания контент элементов. Их администрирование, заполнение и так далее. Я понимаю как это работает в cms но не на Laravel.
Здравствуйте, посмотрел много ваших видео и хотел спросить, если посмотреть все ваши платные курсы по ларавел, можно ли уверенно идти на работу на позицию jun?
Более чем
Можно видео-обзор для jetstream?
Есть же канонический перевод - "Предметно-ориентированный дизайн". Гораздо точнее отражает суть, чем "на основе".
Тема DDD не раскрыта
В ObjectValue выбрасывается http exception. Так не хорошо делать, перепрыгивая целый слой
А где у вас на канале раньше были видео по тестам? Вы их закрыли, что ли? Юнит тесты и ещё, кажется, какие-то были.
Может к этому видео не относится, но как на счёт урока про репликацию, master-slave в laravel для Mysql
🙏👍❗
preg_match разве не будет ексепшны выдавать? Там надо ! вроде как поставить. Иначе на киррилицу будет эксепшны выдавать.
В классе Name.
Это пример, там много чего можно сделать:)
расскажи как документацию проекта делать
Благодарю!:)
Условие в методе assertSalaryIsValid должно быть противоположным
Имя можно разделить на first name и last name)
оно в коде так и реализованно
Куда пропал ?
пожалуйста, сделайте 1 задание поменьше, используя DDD внутри laravel
а если у человека фамилия поменяется, а нужно распечатать в старом документе старую фамилию? а если работник уволился, а потом снова устроился? а если полные тезки будут то одно велью будет или два одинаковых? - так это бред?
Стоит использовать phpmyadmin?
тоесть лучше логику в сервисы пихать ?
Ну вообще от ситуации, если логика какая то сложная, ты можешь ее вынести в доменный слой приложения, так Адель писал☝️. От случая зависит
если речь про бизнес логику то да. А если про логику поведения объекта то что-то лучше добавить в методы объекта. На пример, сущность Квартира, у неё есть общая площадь, которая вычисляется на основе суммы площадей входящих в неё помещений. А вот если нужно применить какой либо коэффициент то лучше вызвать этот метод где-то в методе сервиса, и в случае изменения коэффициента или ещё чего, добавить дополнительный метод.
@@hotis8 а в чем разница от бизнес логики я не понял
@@artemunix5223 коротко для себя это сформулировал так - в объекте только та логика которая от бизнес-процессов не зависит.
Здравствуйте, интересует вопрос, а не хотели бы Вы, или, возможно, у Вас есть в планах, начать рассказывать про Symfony?
0. ни слова о том, зачем ДДД.
1. схема с ддд в описании архитектур не верная. Репозиторий ни когда не знает ничего о вьюхах. А на схеме - знает и много.
2. Энтити отличается от value-object тем что имеет уникальный идентификатор для каждого экземпляра и обычно экземпляры мутабельны.
3. сила интерфейсов к репозиториям в том, что реализация этих репозиториев может быть разной, под разные хранилища. При этом доменной модели на это плевать.
4. ни слова не сказано про DTO. А ведь именно они пробрасываются между слоями.
5. Salary не может быть value-object. Оклад - может, зарплата - нет. Поскольку зарплата включает в себя штрафы, надбавки и т.п. И вполне себе может иметь айди.
Реестр сотрудников не является адекватным примером предметной области. Для такого приложения не нужно даже городить никакое DDD.
Достаточно интерфейса к базе данных с некоторыми проверками.
Предметной областью может быть вся фирма, если там действительно есть сложная бизнес-логика. Иначе достаточно CRUD приложения.
Сущность не является предметной областью.
Короче, слышал звон да не знаю где он, из DDD тут только набор непонятых автором терминов.
Спасибо автору. Но почему репозиторий описан в доменном слое. Разве домен не обязан быть в неведении относительно репозиториев?
никто никогда при разговоре про DDD не говорит ЗАЧЕМ и КАК с этим потом работать?
опять одна вода и 0 путных мыслей, сколько раз еще такие ролики будут иметь место?
нахрена к ларавелю это всё прикручивать и изобретать велосипед?
как их между собой вязать, если в ларе модели друг к другу вяжутся нормально, как объекты в БД со связами через внешние ключи, то здесь всё, приехали ваши вэлью обжекты существубт сами по себе, как их коннектить друг к другу непонятно, вы проигрываете в скорости, во всём, все сущности у вас теперь атомарны, ни о каких джойнах теперь речи не идёт, вы просто всё разделили, запросов в БД больше, удобства меньше
зачем здесь DTO если у вас уже и там ValueObject? хоспади, есть ощущение что вы вообще не понимаете что вы делаете и для чего, это какие-то понты без обоснования, типа смотри как могу
никто не отвечает на эти вопросы, загадка остаётся нерешённой
ладно, в конце вроде нормально раскрыл, забираю свои выебоны обратно
++. Как опытный велосипедист, всегда вижу когда педали не в ту сторону крутятся. Нужен адаптированный ДДД под прекрасные модели ларавел, может быть не очень правильный но всё же.
@@zxc7613 фреймворки для того, чтобы бить по рукам, но когда на уже существующие пытаются наслоить что-то еще своё, я бы пиздил еще и ногами
@@litvinenkow ахахахха