Тот момент когда слушаешь и думаешь что все не так просто, пока не увидешь пример. По нему все становится на свои места и ты понимаешь что такое домен, и какая основа у данного подхода. Ведь нового там нечего нет. Просто все грамотно разбивается на части, но с использованием всех тех же паттернов которые всем известны.
Круто когда сам сидишь выдумываешь архитектуру, как как было бы структурированее и удобнее, а тут бац, умные дядьки уже такое придумали, ценно до чего сам дошёл.
Дело в том, что умные дядьки дошли до этого в 80-е и 90-е годы, поэтому нельзя сказать, что Вы совсем самостоятельно это придумали. Слышали, видели, сталкивались в чужом коде так или иначе… Это теперь уже стало нормой, но не всегда так было
@@dmitrydmitriy9912 На самом деле нет. Я пришел к подобному не потому что я видел, а потому что пытался написать свой проект 15 раз. И с каждым разом я был немножко ближе к этой структуре. Я пишу на PHP, и в моем контексте, ни один фреймворк не предлагает этого.
Братан, тебе нужно тренироваться, воюешь пока не туда ваще. 1) 04:06. "На основании контекста код разделяют на папки / файлы / пакеты / компоненты...". Нет, это не так. Ограниченный контекст это действительно граница, в рамках которой живет модель предметной области, то есть границы решения определенной проблемы. Но ограниченный контекст также имеет 2 важных свойства: 1. Физические границы - ограниченный контекст является независимо разворачиваемым объектом (микросервис / монолит). И разделение соответственно всегда ФИЗИЧЕСКОЕ , а не на папки и файлы, как ты говоришь. То есть 2 ограниченных контекста не могут жить в рамках одной кодовой базы какого-то сервиса. В этом его и основная польза, как бы защита от дурака. Даже если разработчик другого ограниченного контекста захочет внести изменения в твой, то это будет максимально проблематично. 2. Границы владения - только одна конкретная команда можно разрабатывать конкретный ограниченный контекст. Пересечений быть не может.
Утверждение, что DDD ускоряет процесс проектирования, требует одной ремарки. Обычно пишут, что DDD на начальном этапе сильно завышает сложность и требования к разработчикам. В долгосрочной перспективе подход имеет значительные плюсы. Но только при условии, что изначальная архитектура была грамотно продумана. Т.е. редко.
Сейчас работаю с dbt. Штука интересная, про нее было видео? Про чистую архитектуру тоже интересно, хотя как уложиться про нее в формате такого видео, представить сложно.
@@mirinfanoНет, ютуб сломался скорее всего. Сейчас проверил, на других видео тоже открывается ссылка с троеточием вместо полной и ведёт на 404 код абсолютно везде.
Про Кафку уже пару видео было (про саму Кафку и про сравнение её с "кроликом"): th-cam.com/video/Mw9YFay8-WM/w-d-xo.htmlsi=jmrzODRTpmT2I7ob th-cam.com/video/QRmGgixERKs/w-d-xo.htmlsi=mdZzw-pAz1jTSrkw
Я не понимаю чем обусловлено огромное количество подписчиков на этом канале? Все ваше видео это по сути куча слайдов с текстом других людей в пиксельном сетапе. Это просто жесть какой неприятный способ потреблять информацию...
вот из-за таких как ты DDD сейчас и плохой , что не проект то никто не знает как с ним работать, я понимаю что ютуб это больше развлекательная платформа, и ты просто хочешь заработать , ну каждому своё
7:20 тот момент когда ты уже несколько лет работаешь по DDD и только это понял =) я считал, что это просто здравый смысл
Жиза
Конечно, интересно было бы послушать про чистую архитектуру. Спасибо за труд!
+ за Clean arch.
Вы делаете очень важную вещь для мира IT, спасибо.
Плюсую за чистую архитектуру. Спасибо за видео!
Огромное спасибо! Снетерпннием жду видео про чистую архитектуру, в Вашем исполнении. 😊👍
Ddd и чистая архитектура это разве не одно и тоже?
@@Deletedeletedelete совсем не одно и тоже. А ещё бывает архитектура вертикального среза. 😉
Тот момент когда слушаешь и думаешь что все не так просто, пока не увидешь пример. По нему все становится на свои места и ты понимаешь что такое домен, и какая основа у данного подхода. Ведь нового там нечего нет. Просто все грамотно разбивается на части, но с использованием всех тех же паттернов которые всем известны.
Буквально на днях учил ООП и услышал про DDD. Спасибо за видео.
Аватарка у тебя имперская
@@1234yyyy Ну почти. Какие-то вопросы?
Пока забей на DDD. Это, как правило, для больших проектов.
Эта болтавня про ДДД и нужна для тех кто вчера учил ООП.
Круто когда сам сидишь выдумываешь архитектуру, как как было бы структурированее и удобнее, а тут бац, умные дядьки уже такое придумали, ценно до чего сам дошёл.
Дело в том, что умные дядьки дошли до этого в 80-е и 90-е годы, поэтому нельзя сказать, что Вы совсем самостоятельно это придумали. Слышали, видели, сталкивались в чужом коде так или иначе… Это теперь уже стало нормой, но не всегда так было
@@dmitrydmitriy9912 На самом деле нет. Я пришел к подобному не потому что я видел, а потому что пытался написать свой проект 15 раз. И с каждым разом я был немножко ближе к этой структуре. Я пишу на PHP, и в моем контексте, ни один фреймворк не предлагает этого.
Фига се, я оказывается все свои бэки по DDD делал :)
Всегда казалось это супер очевидным. Не знаю про что можно целые книги писать.
На данный момент жизни DDD это дни до дома :D
Братан, тебе нужно тренироваться, воюешь пока не туда ваще.
1) 04:06. "На основании контекста код разделяют на папки / файлы / пакеты / компоненты...". Нет, это не так. Ограниченный контекст это действительно граница, в рамках которой живет модель предметной области, то есть границы решения определенной проблемы. Но ограниченный контекст также имеет 2 важных свойства:
1. Физические границы - ограниченный контекст является независимо разворачиваемым объектом (микросервис / монолит). И разделение соответственно всегда ФИЗИЧЕСКОЕ , а не на папки и файлы, как ты говоришь. То есть 2 ограниченных контекста не могут жить в рамках одной кодовой базы какого-то сервиса. В этом его и основная польза, как бы защита от дурака. Даже если разработчик другого ограниченного контекста захочет внести изменения в твой, то это будет максимально проблематично.
2. Границы владения - только одна конкретная команда можно разрабатывать конкретный ограниченный контекст. Пересечений быть не может.
Утверждение, что DDD ускоряет процесс проектирования, требует одной ремарки. Обычно пишут, что DDD на начальном этапе сильно завышает сложность и требования к разработчикам. В долгосрочной перспективе подход имеет значительные плюсы. Но только при условии, что изначальная архитектура была грамотно продумана. Т.е. редко.
если честно не понял, что так с этим термином носятся. довольно очевидные вещи.
Классная штука) пишу на go, использую гексагональную архитектуру и она следует принципам DDD, что очень удобно
Наоборот, тактический ddd следует принципам гекс архитектуры
DDD - это бренд одежды от кутюрье Дениса Дыркина
именно так и делал проект свой, и только сейчас понял, что это и было DDD
Сейчас работаю с dbt. Штука интересная, про нее было видео? Про чистую архитектуру тоже интересно, хотя как уложиться про нее в формате такого видео, представить сложно.
давай про чистую архитектуру!
за чистую архитектуру)
За чистый андройд,за чистое ПО..!
Подскажите подажалуйста как делают такие видео? Как делают такую анимацию и где об этом модно узнать подробнее? Оочень буду благодарен вам за ответ)))
Скорее всего, это Adobe After Effects. Учебных материалов по нему полно.
давай по clean architecture
Откуда звук в начале видео?
Подсказка: палатка первой помощи 😉
@@ListenIT_channel вместо видео, я пытался вспомнить откуда же этот звук😄догнал спасибо)
@@vladislavkramskoy4382Из Героев, сразу обратил внимание )
DDD - дай дорогу дураку
У вас ссылки в описании кривые, на троеточии обрываются
Ты на ссылку нажми, всё работает
@@mirinfanoНет, ютуб сломался скорее всего. Сейчас проверил, на других видео тоже открывается ссылка с троеточием вместо полной и ведёт на 404 код абсолютно везде.
О звукарь фанат героев 😅
Дай Дорогу Дураку
Выбился из тайминга
Kafka давай
Про Кафку уже пару видео было (про саму Кафку и про сравнение её с "кроликом"):
th-cam.com/video/Mw9YFay8-WM/w-d-xo.htmlsi=jmrzODRTpmT2I7ob
th-cam.com/video/QRmGgixERKs/w-d-xo.htmlsi=mdZzw-pAz1jTSrkw
Что ни сделают троечники, лишь бы не осваивать idef0 🤣🤣🤣
Само собой, что вменяемого примера не получилось, ибо чушь собачья 🤦🏼♂️
Я не понимаю чем обусловлено огромное количество подписчиков на этом канале? Все ваше видео это по сути куча слайдов с текстом других людей в пиксельном сетапе. Это просто жесть какой неприятный способ потреблять информацию...
00:25 "домэйн ДРИВЕН дизайн"
Ну ебаный стыд, а
Что не так?
Тоже не очень понял, в чём стыд) Подскажешь?
вот из-за таких как ты DDD сейчас и плохой , что не проект то никто не знает как с ним работать, я понимаю что ютуб это больше развлекательная платформа, и ты просто хочешь заработать , ну каждому своё