"Великаны не так просты, как кажется, великаны - они как лук. Многослойные!" (с) Шрек

@user-me6vb7gw9c

10 ай бұрын

зашёл ради этого коммента

@arturhimself

10 ай бұрын

«Ты запутался в своих слоях, лучок» 😂

@palkan2590

10 ай бұрын

@@arturhimself я ждал тебя

@alexpavlenko4719

10 ай бұрын

Воняют. Доводят до слёз.

@BestDron

10 ай бұрын

Все обьесняют это архитектуру очень сложно. Я понимаю её так. 1: Есть слой Core- в нём есть слой Domen и Application 2: в слой application адаптеры для внешних сервисов бд. и ui и ТД. В нём же находиться бизнес логика приложения он зависит только от слоя Domen. 3: Domen слой самый независимый он не чего незнает о других слоях. Вся связь между предметной областью и другими частями приложения в слои Application он знает о бо всех слоях, но лучше через интерфейсы. Главный принцип слой домена независимый.

Ура! Мы ждали. С возвращением🎉 Спасибо за труды!

Ждал продолжения серии видео по архитектуре, очень полезно! Спасибо Жду чистую архитектуру, гексоганальную, реактивную

Смотрю 3й ролик, ты умеешь хорошо, чётко, без воды всё объяснить. Спасибо за работу!

Очень наглядно предоставлена информация!!! спасибо, Тимур, за ваш труд! Визуал максимально понятный и эстетичный!

Тимур, спасибо за ролик, как раз во время. Качество контента и обновленный визуал радует!

Кстати отличное объяснение инверсии зависимостей и внедрения зависимостей. Почти в любой литературе примеры настолько абстрактные что пока на практике не столкнешься не поймешь. Спасибо за видео! Просто лучший!

Спасибо! ❤👍 Поздравляю с защитой!

Лучший! Учу C++ но периодически смотрю твой канал для расширения кругозора, ведь те вещи о которых ты говоришь также хорошо ложатся и на другие ЯПшки. Обнял, поднял)

Классно визуализируешь подачу, объясняешь, спасибо!

Все четко и доступно! Спасибо!😊

сначала лайк не глядя, потом смотрим спасибо, Тимур) пошел смотреть

Спасибо большое! Как всегда, очень понятное объяснение))

@UlbiTV Отличный ролик, очень хорошо описал суть DI и то, как изолироваться от базы данных и прочей инфраструктуры 👍. Единственное отмечу один анти-паттерн, который ты используешь. Это анемичная доменная модель. По-хорошему в больших сложных проектах Логику нужно не просто класть в service. А распределять между 3-мя объектами: service, entity, value object. И, как правило, чем правее, тем лучше. Потому что если всё писать в сервисе, один метод может разрастись на 100 строк и вместо читаемой бизнес логики ты получишь так называемые transaction scripts. Transaction scripts и анемичные модели могут нормально работать в простых кейсах, без большого количества логики. Но если у вас большой сложный домен, это становиться гораздо труднее читать, поддерживать, понимать и т.д. Доменная модель - это не описание данных, это в первую очередь описание поведения тех или иных сущностей, а данные второстепенные и по возможности инкапсулируются, а объекты этой доменной модели являются не "глупыми", а "умными", они содержат методы и value object-ы которые тоже содержат свои методы. Для саморазвития в этом направлении рекомендую книжку: Implementing Domain-Driven Design А также статьи: fowler: - martinfowler.com/bliki/AnemicDomainModel.html - martinfowler.com/bliki/ValueObject.html enterprise craftsmanship: - enterprisecraftsmanship.com/posts/domain-vs-application-services/ - enterprisecraftsmanship.com/posts/nesting-value-object-inside-entity/ - И много других интересный статей - enterprisecraftsmanship.com/posts Не для того, наверное, ООП было придумано, чтобы императивно писать всю логику в сервисах =)))

@AmirLatypov

3 ай бұрын

И тем не менее, от ООП продолжаем уходить ;). Чтобы был не один большой сервис, можно сделать несколько. Передавать «глупые» структуры данных намного легче и надежнее, чем умные модели. Во всяком случае долгосрочно. Поэтому Unix way подход - функция принимает на вход данные, а не классы со своим внутренним миром.

Спасибо за ролик! Во время просмотра была мысль, что визуал очень приятный. Донесение сути информации без воды тоже радует "Чистой архитектура" Роберта Мартина - замечательная книга

Очень круто! Спасибо большое за видео!

Спасибо большое за разжеванный контент! Я закрыл практически все свои пробелы в знаниях backend. Очень редко пишу комментарии, но хотел тебя под бодрить тебя своим комментарием. Я очень расстроен что подобные ролики получают мало просмотров. Удачи!

Все по полочкам, супер!🎉 Спасибо

Все четко и по делу. Спасибо!!!

Круто, спасибо большое. Очень детально и интересно

Супер! Очень полезный ролик! Спасибо

Привет. С возвращением. С защитой диплома. 🎉

Отличный видос, ждем новых. Обнял-приподнял :D

Тимур, большое спасибо! Отлично объяснил!

С такой структурой как начал работать, сразу стал кайфовать

Крутой видос, большое спасибо)

было бы прекрасно посмотреть реализацию на разных архитектурах, т.е. не маленькие условные примерчики, а конкретную реализацию

@user-ru6qv3vp6p

10 ай бұрын

есть в курсе у улбика

Большое спасибо за контент, очень грамотно объясняешь! Смотрел твои видео по vue, очень сильно помогли, особенно трехчасовое Очень бы хотел еще один урок с vue 3, nuxt и typescript Думаю зайдет шикарно

Огромное спасибо, очень полезное видео)

Спасибо за ролик! Все четко и понятно объяснили)

Очень круто! 🎉

Просмотрел до конца...подписался,+лайк

Спасибо автору, комментарий в поддержку

Ты вернулся !!!)

Отличный видос, молодец, круто вышло

Спасибо большое за контент!

Тимур, спасибо за такой хороший ролик! И, особенно, за примеры и пояснения. Этот ролик я бы рекомендовал сразу после ознакомления c SOLID принципами, чтобы S и D закрепить.

Братан, поздравляю с защитой диплома, спасибо за контент, ты топ

@helenit4365

10 ай бұрын

Тима, с защитой диплома магистратуры МГУ и получением премии "Прорыв года" в айти!!!!!

@adelinaromanova8353

10 ай бұрын

Ого!!! Поздравляю!!!

Братан, хорош, давай, давай, вперёд! Контент в кайф, можно ещё? Вообще красавчик! Можно вот этого вот почаще?

очень крутой видос СПАСИБО!

Спасибо тебе!

Спасибо, как бы это все ещё понять и собрать.

Как всегда огонь🤯🤯

Спасибо за видос!

Плюсы: звучит вкусно Минусы: хочется плакоть….

@user-lu7mm8bw1m

10 ай бұрын

на самом деле на практике это в разы легче понять )

@yundon8182

9 ай бұрын

Просто Тимур любит утрировать и пугать своим тоном голоса, перечисляя много всякого

@xyzw777

11 күн бұрын

11:55 неа😅, в реальности бизнес модель меняется каждый день, а вот инструментарий почти константа

Очень полезно, спасибо!

Приятное видео!

спасибо за контент!

Очень круто и по-взрослому выглядит эта архитектура. Хотелось бы видос, типа "создание приложения с 0" на её основе

Слоистая архитектура. Луковая (onion) архитектура. Слои, изоляция, DI, solid, спасибо!

написанное в видео очень сильно напоминает нест. очень годное видео, спасибо за объяснения!

Молоток!

топовый контент)

все красиво на бумаге - но забыли про овраги )) надо бы практический курс применения этого всего - уверен там будет куча подводных камней, особенно связка одной доменной модели с другой

Красавчик вообще

спасибо!

🔥🔥🔥

интересно, но не хватает ещё большей конткретики. Было бы круто небольшое приложение запилить по всем традициям луковой архитектуры

Автор супер объясняешь, но ещё будет плюсом если видео будут заточены под телефон) иногда с телефона смотрю, и надписи плохо видно. Вот как пример ютуберы Владилен итд даже через телефон их удобно смотреть, не знаю как они настроили, но думаю можешь взять на заметку)

лучший тимур!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Очень круто описал. Было бы круто видос, прям фулл гайд, как структурировать папки/файлы в проекте и главное как правильно их наименовать. Либо скинь пж, где можно об этом подробнее почитать.

круто !

Монтаж огонь 🔥

Раскрыл луковицу по слоям КРУТО)

крутяк!!!!!!

Очень хотелось бы подробный(как всегда) ролик по FSD🙌

@ilyapro2815

10 ай бұрын

про FSD рассказывалось в рамках другого видео из этого же плейлиста.

Давно ждал, но ты не делал. Пришлось покупать лекцию по ней. Очень крутая тема. Однако в одном видео о ней сложно рассказать, там много подводных камней и кстати первая слойка, Dto называют. Затем уже идёт Сущность например модель пользователя, только потом контроллер и репозиторий. Короче это довольно тяжёлая часть архитектуры и в одном видео показать сложно, но у тебя получилось хотя бы похожее что - то.

❤❤❤

ура❤

Так, походу я понял, надеюсь меня теперь возьмут на джуна с такими знаниями =)

Спасибо, очень интересно. Как бы хотелось пример использования этой архитектуры во фронте... Не совсем понимаю где в этом случае будет логика обработки ошибок в каком-нибудь формуляре.

Хотелось бы увидеть пример такой слоистости на Реакт или Вью

@ell1ar

10 ай бұрын

Луковая архитектура под бэкенд. Под фронтенд всякие FSD, модульные простые архитектуры

Был бы очень благодарен за объяснение от тебя технологии grpc

Спасибо за видео. Но есть ли пример, пусть и не большого, но рабочего проекта с использованием такого подхода? Google много выдает такого. Но хотелось бы услышать от тебя: «вот репозиторий на GitHub с проектом в котором хорошо показано принципы и подходы о которых я говорил»

Привет! Тимур! В каком редакторе делаешь такие видео? PS: В старых видео мелковат шрифт бывает, в этом показался крупноват.

IoC контейнер, все-таки ) предыдущие видео очень хорошо все было, тут немного сумбурно ( ну и всем посмотревшим - все это очень сложно осознать без практики, и как сказал Тимур - не сущестует архитектуры, прибитой гвоздями )

Спасибо. Вопрос: можно ли без type script на java script имплементировать такую архитектуру?

@tetraf0ur

10 ай бұрын

да

Я смотрел курс архитектуры на джаве, у них там какой-то персистенс слой часто фигурирует. Что бы он мог делать?

Извини меня за вопрос не по теме, но какую версию вебшторма ты используешь? Тк на последней версии 2022 и 2023.1 при работе с MUI дико фризит

С чего начать изучать программирование: с PHP или c++/c#?

Топ контент

Примерно архитектура Angular, как я понял

Для новичков в жтой теме ок видео. Но если копать глубже, то стоило хотя бы поговоить про use case на слое сервисов и анемичные модели и их проблемы на слое домена. Слой сервисов тоже описан не оч хорошо как и слой домена. Опять таки обычно слоистая арзитектура за ручку с ддд идёт в паре, а это тоде тема нн простая. Крч как по сне наверное стоило сделать серию роликов, которая почтепенно углублялась бы, ечли всё-таки стремиться к более полной картине. Если такого стремоения у автора нет, то и так как есиь сойдёт.

Лучшая архитектура серверного приложения, как по мне - это EDA (Event Driven Architecture), то есть основанная на событиях. Потому что сервер лучше всего работает в асинхронном событийном режиме, в режиме реагирования на события. И особенно хорошо, если построено всё по DDD.

@xyzw777

11 күн бұрын

в банке нужно было перегнать кучу объектов, посчитали миллион шт/час через асинхронное апи, миллиард шт/час из одной бд в другую... как думаете что руководство банка подумало о EDA\DDD и т.п. в этот момент ;)

@kades7

11 күн бұрын

@@xyzw777 пф, а где вы видели приложение, которое напрямую гоняет данные между БД? Сравнение вообще не корректное.

@xyzw777

10 күн бұрын

@@kades7 erp\pdm и т.п. гонять данные между бд это etl, а обмен между разнородными источниками свойство нормальной бд

@kades7

10 күн бұрын

​@@xyzw777 для всего свои инструменты. Без EDA/DDD вы не сделаете нормальную распределённую систему, у вас всегда будет монолит со всеми его недостатки в сложной системе (спагетти, связность). А такая вещь как перегонка данных между базами - это не относится к общей архитектуре приложения, это может быть всего лишь частью сложной системы, которая построена по EDA, но внутри каждого модуля, конечно же, монолит. EDA - это клей между независимыми монолитными модулями. Без него у вас будет монолит из монолитов. А с ним у вас распределённая система, состоящая из монолитных модулей.

@xyzw777

10 күн бұрын

@@kades7 производительная система всегда монолит. никто не мешает десяткам бд обмениваться инфой без костылей "внешнего" чужеродного кода, вопрос лишь для чего: горизонтальное масштабирование или отделение своей части от частей другого программиста. например на sql view с тригерами mssql я как-то написал учетную систему у которой не было ни одной строки "внешнего" кода, т.к. клиент был ms access где формочки сделаны мышью... как видите ни то что луковой архитектуры не понадобилось но и вообще фронт\ui разработчиков как таковых. _"спагетти, связность"_ вряд-ли вы про goto, только вы знаете что имели в виду

Очень хорошее видео, автор крут овсе объясняет. Я только не понял зачем перегонять ответ из БД в другую ДТО в Кор слой? Если мы используем ОРМ мы и так оттуда достанем полноценную Энтити. И еще вопрос. Вот как говорит автор мы делаем несколько интерфейсов Репозиториев и имплементим их в сервисы, что бы потом можно было лекго подменить реализацию, будь то из файла или из БД. А вот если нам надо будет Юзера достать с другого Апи например, как это правильно сделать?? Предположу что делаем некий Провайдер интерфейс и инжектим его в новый Репозиторий ??? и уже на сонове этого провайдера реализуем методы репозитория??? А если в дальнейшем будет несколько версий Апи, то нам уже придется делать провайдер интерфейс и на его основе реализовывать разные провайдеры и инжектить их в репозитории???

Здравствуйте! Какие курсы по javascript с нуля посоветуете на ютубе?

Ulbi TV Привет, у меня идея. Смотри, есть понимание, что js - это однопоточный язык, а как на счет того что бы записать видео о том, как можно имулировать многопоточность используя микротаски. Мне кажется, это интересный сюжет для видео. Подобного контента в интернете кажется нет, а статьи написаны на эту тему поверхностно. Будет круто если ты сможешь объяснить на практике такую задачу. Вообще многопоточность на js, это и в прям немного не обычно как я считаю. Что думаешь?

Немного запутался. Правильно ли я рассуждаю. Получается что в domain model мы создаем интерфейсы моделей. В repository пишем интерфейсы для бизнес логики. А в services мы реализуем эту логику. А на слое infrastructure мы уже используем наши сервисы? Или же реализуем новый функционал, например связь с бд, на основе тех интерфейсов, что находятся в ядре. Верно рассуждаю?

8:22 как создание/удаление чего-либо в системе может НЕ зависеть от БД? и КАК взаимодействие с БД может быть там же, где UI/API/Обработчики/Контроллеры ??

Интересно узнать мнение: важно ли согласовывать архитектуру бэкенда и фронтенда? Есть ли какие-то более удачные варианты использования архитектур фронта и бэка, которые дают приемущество? Например, слоистая на бэке + микрофронтенд = ...

@Fartek2

10 ай бұрын

это два независимых приложения, они никак не должны быть связаны никакой архитектурой

@BestDron

10 ай бұрын

Swager в помощь, и все проблемы решаются. Архитектура Бека зависит от безнес задачи. Иногда нахер не нужны все эти архитектуры и люди натягивают сову на глобус.

Неплохое видео, но. 1) то что вы называете слоями - я бы назвал функциональным назначением. Ибо получается что 3 "внутренних слоя" и создают ядро домена. А если модель у вас лежит ниже всех - то она не может не от кого зависеть и получится как минимум анемичной (что не всегда удобно, но надёжнее). Обычно выделяют Data (откуда и куда данные берутся) / Domain (бл) / View(как это попадёт в глаза юзеру - форматирование, локаль и тд) layer. (можно ещё выделить application / render layer) 2) архитектура = правила устройства системы. А отражаться они могут в названиях файлов, папок, классов, методов и тд. Так и в том, кто от кого может зависеть, а кто нет. Ну и какой код в какой функциональный файл (модель, контроллер, кейс и тд) ложить. 3) я бы сказал что универсальные архитектуры существуют. Только для большинства проектов это будет оверинжиниринг. 4) лучше, как по мне, разбивать папки так = слой > сущность > функционал. Из сущностей можно делать удобные модули для DI. 5) не хватает упомянания DDD как связующего всех этих архитектурных стилей и подходов

Можно не обьяснить один момент пожалуйста. В контроллере создается DTO объект и передается там в сервис, например, чтобы записать в БД. Там, для записи в БД, эти данные конвертируются в другие структуры из db/entities. Так вот, для чего тогда вообще структуры из core/entities?

Сколько разработчиков и какого уровня нужно закладывать бизнесу? Если бизнес поведется на сею луковицу рассуждений

А можно ли в других сервисах использовать другие, и например использовать один сервис и там и там?

@gevorgmovsisyan5153

10 ай бұрын

Да, вес смысл в этом

Есть источники с тематичечкой литературой для новичков?

Вопрос касаемный DTO. Если мы пишем приложение на TS, то зачем эти DTO определены ввиде классов? Разве мы не можешь для описание этих данных использовать те же интерфейсы?

Like

Мне интересно как часто разработчики меняют орм или фреймворк или хотя бы базу данных на больших проектах?

@gizmolo4

10 ай бұрын

не часто. Но вот приделывать какой-нибудь кэш - вполне себе частая история, и когда у тебя хранение отделено от логики, это все делается буквально одним движением руки

Делай еще паузы после предложений, а то воспринимается все как одно и как то можно еще обозначать переход к следующему абзацу/главе, чтобы зритель мог разделять информацию

Боже! Свершилось братцы. На примере фронта мы узнаем как работают технологии бека))