Слоистая архитектура. Луковая (onion) архитектура. Слои, изоляция, DI, solid
HTML-код
- Опубликовано: 25 июн 2023
- В этом ролике мы рассмотрим одну из самых популярных архитектур ПО. Многослойная\слоистая\луковая архитектура. Рассмотрим на примере. Поговорим про Dependency inversion и dependency injection
Курс "Продвинутый Frontend. в Production на React" - ulbitv.ru/frontend
Плейлист с роликами по архитектуре - • Архитектура ПО
Поддержать меня и мой канал вы можете по ссылкам ниже.
Patreon/boosty (доступ к бонусам) - boosty.to/ulbitv
Qiwi кошелек - qiwi.com/n/BODYE821
Яндекс деньги - yoomoney.ru/to/4100116193037469 
Наука
"Великаны не так просты, как кажется, великаны - они как лук. Многослойные!" (с) Шрек
зашёл ради этого коммента
«Ты запутался в своих слоях, лучок» 😂
@@arturhimself я ждал тебя
Воняют. Доводят до слёз.
Все обьесняют это архитектуру очень сложно.
Я понимаю её так.
1: Есть слой Core- в нём есть слой Domen и Application
2: в слой application адаптеры для внешних сервисов бд. и ui и ТД. В нём же находиться бизнес логика приложения он зависит только от слоя Domen.
3: Domen слой самый независимый он не чего незнает о других слоях. Вся связь между предметной областью и другими частями приложения в слои Application он знает о бо всех слоях, но лучше через интерфейсы.
Главный принцип слой домена независимый.
Ждал продолжения серии видео по архитектуре, очень полезно! Спасибо
Жду чистую архитектуру, гексоганальную, реактивную
Ура! Мы ждали.
С возвращением🎉
Спасибо за труды!
Кстати отличное объяснение инверсии зависимостей и внедрения зависимостей. Почти в любой литературе примеры настолько абстрактные что пока на практике не столкнешься не поймешь. Спасибо за видео! Просто лучший!
Смотрю 3й ролик, ты умеешь хорошо, чётко, без воды всё объяснить. Спасибо за работу!
Тимур, спасибо за ролик, как раз во время. Качество контента и обновленный визуал радует!
Очень наглядно предоставлена информация!!! спасибо, Тимур, за ваш труд! Визуал максимально понятный и эстетичный!
Лучший! Учу C++ но периодически смотрю твой канал для расширения кругозора, ведь те вещи о которых ты говоришь также хорошо ложатся и на другие ЯПшки. Обнял, поднял)
Все четко и доступно! Спасибо!😊
Спасибо большое! Как всегда, очень понятное объяснение))
Спасибо! ❤👍
Поздравляю с защитой!
сначала лайк не глядя, потом смотрим
спасибо, Тимур)
пошел смотреть
Классно визуализируешь подачу, объясняешь, спасибо!
Спасибо за ролик! Во время просмотра была мысль, что визуал очень приятный.
Донесение сути информации без воды тоже радует
"Чистой архитектура" Роберта Мартина - замечательная книга
Все четко и по делу. Спасибо!!!
Все по полочкам, супер!🎉 Спасибо
С такой структурой как начал работать, сразу стал кайфовать
Круто, спасибо большое. Очень детально и интересно
Очень круто! Спасибо большое за видео!
Спасибо большое за разжеванный контент! Я закрыл практически все свои пробелы в знаниях backend. Очень редко пишу комментарии, но хотел тебя под бодрить тебя своим комментарием. Я очень расстроен что подобные ролики получают мало просмотров. Удачи!
Тимур, большое спасибо! Отлично объяснил!
Супер! Очень полезный ролик! Спасибо
Отличный видос, ждем новых. Обнял-приподнял :D
Спасибо за ролик! Все четко и понятно объяснили)
Огромное спасибо, очень полезное видео)
Крутой видос, большое спасибо)
@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
Не для того, наверное, ООП было придумано, чтобы императивно писать всю логику в сервисах =)))
И тем не менее, от ООП продолжаем уходить ;).
Чтобы был не один большой сервис, можно сделать несколько. Передавать «глупые» структуры данных намного легче и надежнее, чем умные модели. Во всяком случае долгосрочно.
Поэтому Unix way подход - функция принимает на вход данные, а не классы со своим внутренним миром.
Очень круто! 🎉
Спасибо большое за контент!
Привет. С возвращением. С защитой диплома. 🎉
Спасибо автору, комментарий в поддержку
Как всегда огонь🤯🤯
Спасибо за видос!
Большое спасибо за контент, очень грамотно объясняешь!
Смотрел твои видео по vue, очень сильно помогли, особенно трехчасовое
Очень бы хотел еще один урок с vue 3, nuxt и typescript
Думаю зайдет шикарно
Просмотрел до конца...подписался,+лайк
очень крутой видос
СПАСИБО!
Спасибо тебе!
Ты вернулся !!!)
Спасибо, как бы это все ещё понять и собрать.
Тимур, спасибо за такой хороший ролик! И, особенно, за примеры и пояснения.
Этот ролик я бы рекомендовал сразу после ознакомления c SOLID принципами, чтобы S и D закрепить.
Очень полезно, спасибо!
Отличный видос, молодец, круто вышло
спасибо за контент!
Приятное видео!
написанное в видео очень сильно напоминает нест. очень годное видео, спасибо за объяснения!
Слоистая архитектура. Луковая (onion) архитектура. Слои, изоляция, DI, solid, спасибо!
Братан, хорош, давай, давай, вперёд! Контент в кайф, можно ещё? Вообще красавчик! Можно вот этого вот почаще?
Братан, поздравляю с защитой диплома, спасибо за контент, ты топ
Тима, с защитой диплома магистратуры МГУ и получением премии "Прорыв года" в айти!!!!!
Ого!!! Поздравляю!!!
топовый контент)
спасибо!
Очень круто и по-взрослому выглядит эта архитектура. Хотелось бы видос, типа "создание приложения с 0" на её основе
Красавчик вообще
Молоток!
Плюсы: звучит вкусно
Минусы: хочется плакоть….
на самом деле на практике это в разы легче понять )
Просто Тимур любит утрировать и пугать своим тоном голоса, перечисляя много всякого
11:55 неа😅, в реальности бизнес модель меняется каждый день, а вот инструментарий почти константа
🔥🔥🔥
было бы прекрасно посмотреть реализацию на разных архитектурах, т.е. не маленькие условные примерчики, а конкретную реализацию
есть в курсе у улбика
Монтаж огонь 🔥
круто !
все красиво на бумаге - но забыли про овраги ))
надо бы практический курс применения этого всего - уверен там будет куча подводных камней, особенно связка одной доменной модели с другой
Раскрыл луковицу по слоям КРУТО)
лучший тимур!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Автор супер объясняешь, но ещё будет плюсом если видео будут заточены под телефон) иногда с телефона смотрю, и надписи плохо видно. Вот как пример ютуберы Владилен итд даже через телефон их удобно смотреть, не знаю как они настроили, но думаю можешь взять на заметку)
Очень круто описал.
Было бы круто видос, прям фулл гайд, как структурировать папки/файлы в проекте и главное как правильно их наименовать. Либо скинь пж, где можно об этом подробнее почитать.
Давно ждал, но ты не делал. Пришлось покупать лекцию по ней. Очень крутая тема.
Однако в одном видео о ней сложно рассказать, там много подводных камней и кстати первая слойка, Dto называют. Затем уже идёт Сущность например модель пользователя, только потом контроллер и репозиторий. Короче это довольно тяжёлая часть архитектуры и в одном видео показать сложно, но у тебя получилось хотя бы похожее что - то.
❤❤❤
интересно, но не хватает ещё большей конткретики. Было бы круто небольшое приложение запилить по всем традициям луковой архитектуры
крутяк!!!!!!
ура❤
Так, походу я понял, надеюсь меня теперь возьмут на джуна с такими знаниями =)
Очень хотелось бы подробный(как всегда) ролик по FSD🙌
про FSD рассказывалось в рамках другого видео из этого же плейлиста.
Привет! Тимур! В каком редакторе делаешь такие видео?
PS: В старых видео мелковат шрифт бывает, в этом показался крупноват.
Спасибо, очень интересно.
Как бы хотелось пример использования этой архитектуры во фронте... Не совсем понимаю где в этом случае будет логика обработки ошибок в каком-нибудь формуляре.
Топ контент
Спасибо за видео.
Но есть ли пример, пусть и не большого, но рабочего проекта с использованием такого подхода? Google много выдает такого. Но хотелось бы услышать от тебя: «вот репозиторий на GitHub с проектом в котором хорошо показано принципы и подходы о которых я говорил»
Извини меня за вопрос не по теме, но какую версию вебшторма ты используешь? Тк на последней версии 2022 и 2023.1 при работе с MUI дико фризит
Хотелось бы увидеть пример такой слоистости на Реакт или Вью
Луковая архитектура под бэкенд. Под фронтенд всякие FSD, модульные простые архитектуры
IoC контейнер, все-таки ) предыдущие видео очень хорошо все было, тут немного сумбурно ( ну и всем посмотревшим - все это очень сложно осознать без практики, и как сказал Тимур - не сущестует архитектуры, прибитой гвоздями )
Был бы очень благодарен за объяснение от тебя технологии grpc
Для новичков в жтой теме ок видео. Но если копать глубже, то стоило хотя бы поговоить про use case на слое сервисов и анемичные модели и их проблемы на слое домена. Слой сервисов тоже описан не оч хорошо как и слой домена. Опять таки обычно слоистая арзитектура за ручку с ддд идёт в паре, а это тоде тема нн простая. Крч как по сне наверное стоило сделать серию роликов, которая почтепенно углублялась бы, ечли всё-таки стремиться к более полной картине. Если такого стремоения у автора нет, то и так как есиь сойдёт.
Ulbi TV Привет, у меня идея. Смотри, есть понимание, что js - это однопоточный язык, а как на счет того что бы записать видео о том, как можно имулировать многопоточность используя микротаски.
Мне кажется, это интересный сюжет для видео. Подобного контента в интернете кажется нет, а статьи написаны на эту тему поверхностно. Будет круто если ты сможешь объяснить на практике такую задачу. Вообще многопоточность на js, это и в прям немного не обычно как я считаю. Что думаешь?
Примерно архитектура Angular, как я понял
С чего начать изучать программирование: с PHP или c++/c#?
Немного запутался. Правильно ли я рассуждаю. Получается что в domain model мы создаем интерфейсы моделей. В repository пишем интерфейсы для бизнес логики. А в services мы реализуем эту логику. А на слое infrastructure мы уже используем наши сервисы? Или же реализуем новый функционал, например связь с бд, на основе тех интерфейсов, что находятся в ядре. Верно рассуждаю?
Спасибо. Вопрос: можно ли без type script на java script имплементировать такую архитектуру?
да
Я смотрел курс архитектуры на джаве, у них там какой-то персистенс слой часто фигурирует. Что бы он мог делать?
Интересно узнать мнение: важно ли согласовывать архитектуру бэкенда и фронтенда? Есть ли какие-то более удачные варианты использования архитектур фронта и бэка, которые дают приемущество? Например, слоистая на бэке + микрофронтенд = ...
это два независимых приложения, они никак не должны быть связаны никакой архитектурой
Swager в помощь, и все проблемы решаются. Архитектура Бека зависит от безнес задачи. Иногда нахер не нужны все эти архитектуры и люди натягивают сову на глобус.
Можно не обьяснить один момент пожалуйста. В контроллере создается DTO объект и передается там в сервис, например, чтобы записать в БД. Там, для записи в БД, эти данные конвертируются в другие структуры из db/entities. Так вот, для чего тогда вообще структуры из core/entities?
Очень хорошее видео, автор крут овсе объясняет. Я только не понял зачем перегонять ответ из БД в другую ДТО в Кор слой? Если мы используем ОРМ мы и так оттуда достанем полноценную Энтити.
И еще вопрос. Вот как говорит автор мы делаем несколько интерфейсов Репозиториев и имплементим их в сервисы, что бы потом можно было лекго подменить реализацию, будь то из файла или из БД. А вот если нам надо будет Юзера достать с другого Апи например, как это правильно сделать??
Предположу что делаем некий Провайдер интерфейс и инжектим его в новый Репозиторий ??? и уже на сонове этого провайдера реализуем методы репозитория???
А если в дальнейшем будет несколько версий Апи, то нам уже придется делать провайдер интерфейс и на его основе реализовывать разные провайдеры и инжектить их в репозитории???
Неплохое видео, но.
1) то что вы называете слоями - я бы назвал функциональным назначением. Ибо получается что 3 "внутренних слоя" и создают ядро домена. А если модель у вас лежит ниже всех - то она не может не от кого зависеть и получится как минимум анемичной (что не всегда удобно, но надёжнее). Обычно выделяют Data (откуда и куда данные берутся) / Domain (бл) / View(как это попадёт в глаза юзеру - форматирование, локаль и тд) layer. (можно ещё выделить application / render layer)
2) архитектура = правила устройства системы. А отражаться они могут в названиях файлов, папок, классов, методов и тд. Так и в том, кто от кого может зависеть, а кто нет. Ну и какой код в какой функциональный файл (модель, контроллер, кейс и тд) ложить.
3) я бы сказал что универсальные архитектуры существуют. Только для большинства проектов это будет оверинжиниринг.
4) лучше, как по мне, разбивать папки так = слой > сущность > функционал. Из сущностей можно делать удобные модули для DI.
5) не хватает упомянания DDD как связующего всех этих архитектурных стилей и подходов
8:22 как создание/удаление чего-либо в системе может НЕ зависеть от БД?
и КАК взаимодействие с БД может быть там же, где UI/API/Обработчики/Контроллеры ??
Лучшая архитектура серверного приложения, как по мне - это EDA (Event Driven Architecture), то есть основанная на событиях. Потому что сервер лучше всего работает в асинхронном событийном режиме, в режиме реагирования на события. И особенно хорошо, если построено всё по DDD.
в банке нужно было перегнать кучу объектов, посчитали миллион шт/час через асинхронное апи, миллиард шт/час из одной бд в другую... как думаете что руководство банка подумало о EDA\DDD и т.п. в этот момент ;)
@@xyzw777 пф, а где вы видели приложение, которое напрямую гоняет данные между БД? Сравнение вообще не корректное.
@@kades7 erp\pdm и т.п. гонять данные между бд это etl, а обмен между разнородными источниками свойство нормальной бд
@@xyzw777 для всего свои инструменты. Без EDA/DDD вы не сделаете нормальную распределённую систему, у вас всегда будет монолит со всеми его недостатки в сложной системе (спагетти, связность). А такая вещь как перегонка данных между базами - это не относится к общей архитектуре приложения, это может быть всего лишь частью сложной системы, которая построена по EDA, но внутри каждого модуля, конечно же, монолит. EDA - это клей между независимыми монолитными модулями. Без него у вас будет монолит из монолитов. А с ним у вас распределённая система, состоящая из монолитных модулей.
@@kades7 производительная система всегда монолит. никто не мешает десяткам бд обмениваться инфой без костылей "внешнего" чужеродного кода, вопрос лишь для чего: горизонтальное масштабирование или отделение своей части от частей другого программиста. например на sql view с тригерами mssql я как-то написал учетную систему у которой не было ни одной строки "внешнего" кода, т.к. клиент был ms access где формочки сделаны мышью... как видите ни то что луковой архитектуры не понадобилось но и вообще фронт\ui разработчиков как таковых. _"спагетти, связность"_ вряд-ли вы про goto, только вы знаете что имели в виду
Здравствуйте! Какие курсы по javascript с нуля посоветуете на ютубе?
Сколько разработчиков и какого уровня нужно закладывать бизнесу? Если бизнес поведется на сею луковицу рассуждений
Like
Вопрос касаемный DTO. Если мы пишем приложение на TS, то зачем эти DTO определены ввиде классов? Разве мы не можешь для описание этих данных использовать те же интерфейсы?
Боже! Свершилось братцы. На примере фронта мы узнаем как работают технологии бека))
доволі непогано коли я починав вивчаиті цибулькову архітектуру.
Делай еще паузы после предложений, а то воспринимается все как одно и как то можно еще обозначать переход к следующему абзацу/главе, чтобы зритель мог разделять информацию
А можно ли в других сервисах использовать другие, и например использовать один сервис и там и там?
Да, вес смысл в этом
Мне интересно как часто разработчики меняют орм или фреймворк или хотя бы базу данных на больших проектах?
не часто. Но вот приделывать какой-нибудь кэш - вполне себе частая история, и когда у тебя хранение отделено от логики, это все делается буквально одним движением руки