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

[@palkan2590]

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

[@ulietaight]

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

[@arturhimself]

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

[@palkan2590]

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

[@alexpavlenko4719]

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

[@BestDron]

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

[@falsetrue7910]

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

[@armenchik_dzhan]

@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]

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

[@Вячеслав-ж1т9ь]

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

[@ded-insult]

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

[@gansgarnett4516]

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

[@ЭзамАппаева]

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

[@АлинаСусликова]

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

[@bobbybob628]

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

[@pesilwoof]

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

[@krimax0]

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

[@НикитаТорбенко]

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

[@helenit4365]

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

[@adelinaromanova8353]

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

[@IlsurGabdulkhakov-w8f]

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

[@СтепашкаСокович]

скорее всего, это одно из лучших русскоязычных видео по архитектуре

[@valbv]

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

[@shittywizzard5727]

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

[@MarkA12]

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

[@НиколайСеливанов-и2в]

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

[@magister-iy7rq]

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

[@ФерзьБлатной-г4н]

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

[@natalyaiv3414]

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

[@1caccount756]

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

[@haykyolyan2511]

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

[@anpoliakov]

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

[@maksimkraev2237]

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

[@artyomsultanov5204]

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

[@vakhr]

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

[@ВикторОрлянский-я5ц]

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

[@gooseman5578]

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

[@some_body_qtyeeuy]

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

[@СтасМилосердов-и6ж]

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

[@Копилкапозитива-щ1ъ]

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

[@nik_markio]

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

[@Akhmad_Dag]

Пишу на Python, но все было четко и ясно. Спасибо!

[@bimal163]

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

[@extense1337]

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

[@darkside2436]

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

[@alpenapple]

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

[@ValentinProtasevich]

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

[@Виктор-н7к4в]

Спасибо, полезное видео. Хорошо изложено. Можно было бы добавить примеров кроме интернет магазина, но все итак предельно структурировано.

[@assetdev1859]

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

[@irinafadeeva1387]

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

[@vitjaz_7591]

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

[@feliche-demiannetliukh3703]

Класный ролик, смотрел ролик по SOLID давно, но только наконец понял DIP. + начал понямимать dependency injection патерн не в призме фреймворка, а больше как паттерн P.S. Класный неон стиль кстати, глаза радует)

[@РоманДиохтиовский]

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

[@ell1ar]

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

[@Sergey.Aleksandrovich.P-37rus]

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

[@Андрій_Ляшенко]

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

[@ilyapro2815]

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

[@АльбертАлександров-ч9ж]

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

[@АртемРащепкин-ф4н]

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

[@kennyotsu4357]

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

[@ИльясЖунусов-э6ч]

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

[@yundon8182]

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

[@xyzw777]

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

[@romanbush5164]

Спасибо наконец-то приходит понимание DDD архитектуры, так вот что это стандартные сервисы и репозитории, слоистая архитектура.

[@vtsel-lp4jv]

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

[@ИльясБикенов]

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

[@eldiiarsaparbekov5397]

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

[@NazarKovalchuk-i6t]

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

[@SeydametBilyalov]

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

[@ivank.5319]

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

[@fgood574]

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

[@abraham3345]

Может проще пересесть на комп чем заставлять автора подстраивать логика как для ПК так и для тлф? Такие видео конспектируются, а не просто смотрятся, с телефона точно этого не сделать

[@fgood574]

@@abraham3345 многие ютуберы делают так. Иногда не хочется садится за пк, или когда едешь куда-то включил через телефон, а потом дома уже продолжил

[@brearey]

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

[@tetraf0ur]

да

[@dima__rx5fw3rm1n]

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

[@meteysh]

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

[@i_ve_given_up]

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

[@Fartek2]

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

[@BestDron]

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

[@cheshiressmile1404]

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

[@роматарасов-о8л]

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

[@iforcewmaster3049]

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

[@НиколайВербило]

Подобное архитектурное решение очень хорошо, и автор выложил материал лаконично и по факту. Но я бы выносил бизнес-логику из сервисов в другие классы и по очень простой причине: бизнес логика не должна ни от чего зависеть. В случае, если она лежит в сервисе, который зависит от репозитория, могут возникнуть сайд-эффекты, а если использовать сервис, как место соединения бизнес-логики и репозитория, то архитектура из ролика превращается в отличнейшую. (Класс с бизнес-логикой не должен ни от чего зависеть. Он должен получить данные, обработать их и отдать)

[@hhullen]

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

[@Andrey_Ks11]

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

[@ПётрПетров-д2ч4х]

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

[@МаксимМухарёв-п8г]

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

[@AntonyMadaliev]

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

[@kronohcr2436]

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

[@vtsel-lp4jv]

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

[@ilyapro2815]

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

[@moranyt8299]

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

[@vendjin]

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

[@Akonitx]

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

[@-dubok-]

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

[@xyzw777]

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

[@-dubok-]

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

[@xyzw777]

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

[@-dubok-]

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

[@xyzw777]

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

[@igor_cojocaru]

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

[@kozii-d]

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

[@Ivan-qp8yd]

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

[@gizmolo4]

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

[@yashkevich8164]

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

[@ya_araik]

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

[@DmitryDemis]

Здравствуйте, в какой программе монтаж делали?

[@seryozhamangushev9638]

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

[@norskiy9765]

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

[@dianadvoryak]

круто !

[@Vedar.]

🔥🔥🔥

[@VanyaMate]

Вопрос связан с DI-контейнером, думаю. А как объяснить ему, какую реализацию нужно подставить, если мы создали несколько? Если вручную указывать, то тут всё понятно, но а если используем DI-контейнер?

[@pc_boyarin1712]

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

[@markeeff3406]

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

[@devKenny]

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

[@seregaant68]

Блин, не понял одного, а как это связать с фреймворками (React, Django, ...)?

[@IlyaKuznetsov1983]

Молоток!

[@AlexanderAlexander-z1d]

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

[@holfizz7868]

ура❤

[@IDontWannaDoThisAnymore]

Спасибо

[@alexseydugin8109]

А в чем разница луковой по сравнению с чистой?

[@andrewskripko2311]

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

[@gizmolo4]

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

[@ГошаТиунов2]

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

[@gevorgmovsisyan5153]

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