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

В этом ролике мы рассмотрим одну из самых популярных архитектур ПО. Многослойная\слоистая\луковая архитектура. Рассмотрим на примере. Поговорим про Dependency inversion и dependency injection
Курс "Продвинутый Frontend. в Production на React" - ulbitv.ru/frontend
Плейлист с роликами по архитектуре - • Архитектура ПО
Поддержать меня и мой канал вы можете по ссылкам ниже.
Patreon/boosty (доступ к бонусам) - boosty.to/ulbitv
Qiwi кошелек - qiwi.com/n/BODYE821
Яндекс деньги - yoomoney.ru/to/4100116193037469

[@palkan2590]

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

[@user-me6vb7gw9c]

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

[@arturhimself]

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

[@palkan2590]

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

[@alexpavlenko4719]

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

[@BestDron]

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

[@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 подход - функция принимает на вход данные, а не классы со своим внутренним миром.

[@falsetrue7910]

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

[@user-zk3bc1lf8k]

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

[@user-if5bk7ee5q]

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

[@yuriuss]

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

[@gansgarnett4516]

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

[@user-ys9po4bp8o]

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

[@bobbybob628]

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

[@user-up2oj4tv8f]

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

[@anpoliakov]

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

[@valbv]

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

[@natalyaiv3414]

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

[@magister-iy7rq]

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

[@user-ru6qv3vp6p]

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

[@maksimkraev2237]

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

[@krimax0]

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

[@ded-insult]

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

[@artyomsultanov5204]

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

[@MarkA12]

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

[@some_body_qtyeeuy]

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

[@vakhr]

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

[@1caccount756]

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

[@user-go4bj1wi8k]

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

[@user-wd7ql4gb6l]

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

[@shittywizzard5727]

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

[@user-hv8kp2oh6f]

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

[@user-sy1wv7yl4n]

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

[@user-ue7lj2to9q]

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

[@ilyapro2815]

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

[@haykyolyan2511]

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

[@irinafadeeva1387]

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

[@nik_markio]

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

[@ValentinProtasevich]

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

[@Sergey.Aleksandrovich.P-37rus]

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

[@vitjaz_7591]

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

[@iforcewmaster3049]

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

[@extense1337]

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

[@ivank.5319]

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

[@user-kh3vy6id3h]

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

[@vtsel-lp4jv]

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

[@user-dw5gp1ou1y]

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

[@helenit4365]

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

[@adelinaromanova8353]

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

[@kennyotsu4357]

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

[@user-lu7mm8bw1m]

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

[@yundon8182]

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

[@xyzw777]

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

[@user-dw8lb8lc7u]

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

[@user-wg2lq7qz7m]

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

[@cheshiressmile1404]

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

[@Akonitx]

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

[@user-ku3bx8we1c]

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

[@fgood574]

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

[@alpenapple]

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

[@eldiiarsaparbekov5397]

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

[@seryozhamangushev9638]

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

[@eunicsi]

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

[@meteysh]

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

[@darkside2436]

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

[@user-lg1tj8ty9o]

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

[@user-ux4le1tf3y]

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

[@user-ky8dr1hu5e]

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

[@AntonyMadaliev]

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

[@vtsel-lp4jv]

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

[@ilyapro2815]

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

[@user-mo1su1zq3h]

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

[@assetdev1859]

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

[@norskiy9765]

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

[@dima__rx5fw3rm1n]

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

[@igor_cojocaru]

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

[@moranyt8299]

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

[@bimal163]

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

[@Andrey_Ks11]

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

[@gizmolo4]

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

[@hhullen]

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

[@kozii-d]

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

[@SeydametBilyalov]

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

[@dianadvoryak]

круто !

[@ya_araik]

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

[@pc_boyarin1712]

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

[@kronohcr2436]

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

[@yashkevich8164]

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

[@devKenny]

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

[@user-lw3lc8yv4d]

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

[@ell1ar]

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

[@brearey]

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

[@tetraf0ur]

да

[@markeeff3406]

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

[@Vedar.]

🔥🔥🔥

[@adammason482]

спасибо!

[@IlyaKuznetsov1983]

Молоток!

[@gabblz480]

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

[@gooseman5578]

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

[@holfizz7868]

ура❤

[@HEX_CAT]

❤❤❤

[@user-my6zv5br1m]

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

[@user-tk4lp2su1u]

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

[@gevorgmovsisyan5153]

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

[@seryozhamangushev9638]

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

[@fan-it]

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

[@gingun95]

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

[@rayrayray4653]

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

[@andrewskripko2311]

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

[@i_ve_given_up]

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

[@Fartek2]

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

[@BestDron]

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

[@-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, только вы знаете что имели в виду

[@Ivan-qp8yd]

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

[@gizmolo4]

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

[@user-vx3yc9lc7u]

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

[@babyzonechanell]

привет ulbi я сейчас почти Junior backend nodeJs developer и хотел спросить могу ли я найти работу в россий

[@alexseydugin8109]

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