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