LARAVEL + Clean Architecture // Роман Постников
Вставка
- Опубліковано 20 сер 2024
- В этом видео Роман поделится главным принципом «Чистой архитектуры», и расскажет как вынести весь фреймворк на внешний слой, от которого не будет зависеть бизнес-логика приложения. Такое решение поможет легко тестировать и поддерживать даже самое большое приложение
Изучайте Git на практике: gogit.ru/
Подписывайтесь на наш канал в Телеграм: t.me/flagstudio
ВК: flagstudio
Instagram: / thisisflagbaby
На языке на котором нет пакетов сложно проверять что у тебя нет лишних зависимостей.
У нас схема такая, есть проекты (каждый проект это отдельный пакет)
Domain
Interfaces (Repositories, Services, Params, Models) ссылается на Domain
Services (Сервисы с бизнес логикой) ссылаются на Domain, Interfaces
Models(модели выходные Rest с док. Swagger)
Persistance(Репозитории, конфигурация Entity) ссылается на Interfaces
Rest(входные модели с валидацией, контроллеры) ссылается на всё так как собирает всё Dependency Injection.
Tests(проект с тестами и всем что нужно для тестов)
Clean Architecture подобно религии все трактует его по разному, на видео один из трактов можно сказать
Очень хороший вопрос был 19:57 - зачем там laravel? И ответа на этот вопрос не было. С таким же успехом проще использовать lumen. 2 месяца на только понимания архитектуры и подхода... интересно, кто то считает финансовую обоснованность таких подходов, или исключительно подход - мы знаем крутые современные решения которые дадут в перспективе 5 лет профи, при условии переезда на новый фремворк. А то что за это время поменяется несколько раз бизнес процесс...
Я бы даже спросил по другому, а зачем там это все "чистое". В целом получается не чистая архитектура, а сложная архитектура, так как чтобы за онбордить в это все нового человека который по какой-то причине не знает что такое "чистая" архитектура уйдет миллион времени. В Laravel и так все сделано таким образом чтобы ты делал максимально понятную архитектуру, единственное что я добавляю слой сервисов и ДТО, но это варьируется от сложности и размера проекта.
@@user-xf5dz5go9v Он несколько раз повторил что это только для больших проектов. В том то и дело что ларавел не диктует никаких правил как делать правильно, слой сервисов в итоге разрастается в такой ком, что становиться в принципе невозможно его использовать не сломав приложение в другом месте, а оставив бизнес логику в другом месте методы достигают тысячей строк кода. Чистая архитектура диктует определенные правила движения данных и зависимостей, поняв их один раз ты легко читаешь чужой код написанный в этом стиле и чувстуешь себя более уверено изменяя или добавляя логику.
@@user-xf5dz5go9v Я видел проекты, которые писали такие разработчики как вы, контролеры в 2 тысячи строк😢 Зачем вам ООП, если вы только наследование используете от туда? И солид же дебилы придумали, да?
@@user-dk1id8nn4o Не понимаю с чего вы взяли что знаете как я пишу код. Просто нужно понимать что использование чего либо должно быть оправданным, я не говорю что solid не нужен я как раз считаю что он нужен, но только в действительно больших или хотя бы средних проектах. Да бизнес логику надо выносить в отдельный слой, опять же сильно зависит от величины проекта. Мне не нравиться когда начинают игнорировать фреймворк и поверх него писать какие-то не очень адекватные структуры по размеру и сложности это не есть хорошо.
Особенно понравилась фраза "Делают одну и ту же задачу..." (ua-cam.com/video/2ZqYhEfFyoc/v-deo.html). Я уже представляю лицо заказчика )))
😂😂😂
Я правильно понимаю что в файле SantaBuilder.php никаких ларавел хелперов и прочего быть не должно, только "голый" php ?
только чистое ООП на пхп
Я не знаю, о каких больших проектах идет речь.... У нас зарубежный проект 100 - 300к запросов в час (среднем 1.5к юзеров в час ) в зависимости от часа пика. Архитектура Laravel сделана таким образом , что на ней можно крутить все в любых позах и как хочешь. В Контроллере максимум 5 строчек кода. Для дублирования и разрастания кода с успехом выносится все в трейты, сервисы и микро контроллеры. Про базу он вообще бред говорит, у нас на проекте 3 базы (на разных языках )+ несколько баз очередей включая на Go и с, для прослоек которые включаются в часы пик.
Но это все слова.
У меня несколько вопросов по факту:
1) Какая нагрузка проекта в час?
2) Сколько памяти проект потребляет на каждую тысячу запросов на архитектуре которую демонстрировали и на классической архитектуре?
3) Мы так и не увидели тесты скорости работы этой архитектуры в сравнении с классической?
4) Зачем использовать Laravel в данной архитектуре , если быстрее будет использовать чистый код? ( иначе нужно убрать 70% модулей фреймворка, которые тянутся паровозом и нагружают дополнительно проект)
5)Как считалась экономическая модель данного проекта если штат растет логарифмически? (то есть проект быстро развивается)
6)Покажите мне этого олуха, который скажет что архитектура Laravel сложна в тестировании? Это один из самых лучших фреймворков для тестирования, проще я даже и не вспомню.
П,С очень много слов, мы так и не увидели микро примера из реальной логики этого проекта.про легкость тестирования мы услышали, но профуф не увидели. Вообщем мое мнение это просто пустой треп людей, у которых не хватает скила писать чистый код на Laravel.
По поводу серверов я так и не понял очем речь? Сейчас 99% хайлоад проектов собирается из слепка на amazon с динамическим разбиением нагрузки на разные машины для стабильной + резервной работы и низкого пинга вне зависимости от числа пользователей. (кроме китайских сервисов) В мире нет аналогов по мощьности и стабильности, я думаю это все прекрасно знают.
Я думаю данный подход и такие костыли сделаны для того, что бы заказчик при желании не смог поменять команду разработчкив и полностью от нее зависил, т.к поменять команду будет дороже, чем писать заново.
Хах, надеюсь вы еще не сошли с ума, вынося все в трейты) Из-за таких разработчиков как вы многие считают php умершим языком, все большие проекты пишутся по чистой архитектуре + DDD. Вы упомянули Go, но 90 процентов проектов на Go пишутся на чистой архитектуре, тинькоф, авито, озон и другие гиганты it-индустрии используют чистую архитектуру, а вы и дальше сидите в своей веб - студии и пилите интернет магазины на MVC структуре
По докладу, без вопросов, есть недочеты, да, можно было показать тестирования и чуть получше раскрыть пример из реальной логики. Но то что вы говорите, что чистая архитектура - это бред, говорит только о вашем узком мышлении и то что вы не принимаете общеизвестные факты, как вредный дед
@@user-dk1id8nn4oу моей команды 248 комитов на гите по проектам ларавел, мы прекрасно понимаем структуру и назначения каждой строчки. Когда мы обсуждаем вектор развития с Тэйлором, он прекрасно дал понять, что все развитие и дальнейшее использование должно быть векторно с доктринной. Я не знаю на каких знаниях основан ваш комментарий. Чистая архитектура на ларавел = это не ларавел. Laravel это доктрина. Можно взять пакеты и собрать все что угодно, но это не будет ларавел и он для этого не предназначен.Прочитайте хотя бы 1 раз доктрину ларавел , потом выпейте таблетки , которые прописал ваш психиатр, подумайте и напишите осмысленно. Резюмируя, зайдите в любой фреймворк и посмотрите что он есть.
Вы из 2005-го? В современной разработке ваши показатели нагрузок, производительности и прочего не имеют никакого значения вообще! Все это решается давно железом, некоторым даже проще через балансировщик еще пару серверов поднять чем профилировать запрос к БД и подбирать индексы.. Железо стоит копейки, дорого стоит разработка и поддержка и это единственное что всем движет.
@@ejoys3 вы правы, только для маленьких проектах
Для такой небольшой задачи, гит можно было и выложить.
сделайте видео как делать мульти язычные теги и мульти язычные страны регионы города например пользоатель выбирает Берлин и в зависимсоти от того на каком языке он пишет подсвечивает нужный город а в поиске Berlin Берлин или другие языки роли не играет
А можно ссылку на гид проекта, чтоб более подробно изучить, спасибо!
а вот, пожалуйста: github.com/OmgProsto/santa-clean
@@FlagStudio оу... огромное вас спасибо!!!!
@@FlagStudio если конечно можно.... не могли бы вы дать контакт человека который на видео, я хотел бы задать пару, а может и нет) вопросов касаемо как то или иное должно быть, еще раз спасибо!
можешь написать их пачкой сюда, а мы пригласим Романа ответить на них
@@FlagStudio Проект тоже на laravel, вот хочу перейти на чистую архитектуру, и есть несколько недопониманий
1. Допустим если использовать модели Eloquent тут все понятно, есть релейшены через которые я могу получить связи к этой таблицей, ОРМ умная и создаст под каждую запись связанную запись модель, а вот как быть в этой ситуации, тут руками создаются Entity и они не такие умные как ОРМ, допустим если это 2 запроса то можно сделать и 2 Entity и после их соеденить, а если нужно сделать выборку 5000 записей, и при этом для каждой записи нужно еще по два релейшена (inner join), это минимум 15000 тысяч запросов, мне кажется это не совсем рациональный расход ресурсов, как быть в такой ситуации?
2. Есть экшен который к примеру должен отдавать (буду на примере своего проекта писать ) коины, а также всякие вспомогательные ссылки по ним, статистику и так далее, есть экшен который должен отдавать только коины, как я понимаю все эти экшены должны возвращать Entity но как мине их заполнять, это должен быть на каждый кейс свой Entity?
Получается появилась задача написать функционал который отдает коины, ссылки на ресурсы коина, историю по коину ( которая в свою очередь тоже формируется из 8 или 9 запросов с разными промежутками) мне для этого нужно написать отдельный Entity, а если нужно будет когда-то сделать чтоб экшен отдавал только коины и историю, мне нужно дублировать Entity который уже был и оставлять только то что нужно для данныго кейса, или в этом случаи нужно использовать агрегаторы и под каждый кей делать свой агригатор, при этом Entity будут только для конкретных скажем таблиц?
3. Еще не совсем понятен момент, не всегда требуется весь напор полей из Entity (таблицы) в этом случаи поля должны быть null или это уже должен быть новый Entity под этот кейс? (если это так то у меня не хватит знаний придумать названий для всех entity :) )
Чуть-чуть подумал и на первый вопрос возможно появился ответ, так как мы в репозитории можем использовать модели в все плюхи которые она предоставляет, тогда весь код который написан в экшене по получению данных мне нужно перенести в репозиторий, все это достать там, распихать все данные по нужным Entity и вернуть из репозитория уже нужный мне агррегатор который будет содержать весь набор нужный Entity для этого кейса, и тогда сам экшен будет состоять просто из одной строчки получить данные из репозиторий, но на сколько хорошая идею засовывать весь код в репозиторий, с таким подходом через 2-3 месяца класс репозитория будет строк так на 20000-30000 тыс?
P.S. Других пока не могу вспомнить, наверно потому что этот самый главный, и я не могу найти не него ответов
Не понятно как вы избавились от ActiveRecord, если он используется в Repository
Я маплю модель ларавеля, на свои - доменные, никто не мешает использовать чистые sql запросы и использовать в репозиториях массивы, также мапить их на доменные сущности
Всегда было непонятно, как валидировать данные в чистой архитектуре? Куда вставить валидацию, если она сложная? Например, валидация зависит от нескольких других моделей, юзера, статусов, и т.п.
Отличный вопрос, у нас тоже было много дискуссий на эту тему. Пришли к выводу, что можно это делать в UseCase-ах, также вызывая интерфейсы. Но есть вариант, прямо в FormRequest, тоже вызывая интерфейсы, но это немного неправильно, таким же успехом можно доменные интерфейсы вызывать из контроллера, но это не так(
Отвязаться от фрейворка, чтобы привязаться к другому. Заказчик всё оплатит, чо. Больше золота
02:04 грубая ошибка в диаграмме, моделька никогда не отправляет в View, этим занимается только контроллер
И вообще в коробке laravel не MVC, а MVCR. Тоесть в ларке роуты является отдельным компонентом, если сравнивать с symfony то внутри контроллера указывается роуты через аннотации или атрибут.
Эта схема не для того чтобы показать течение данных, она просто показывается что все связано, она не несет никакого смысла в себе
Мда.. такое ощущение что видосу лет 10.. так все жиденько.. Ларка очевидно не для того чтобы ее там выпиливать, а для реализации слоя инфраструктуры.. хотя Laravel, Symfony, Yii2 это такой же легаси как и Zend которые зиждиться на плечах адептов которые не понимают зачем на самом деле composer.. И в доменный слой можно затянуть вендора.. тот же вендоровский uuid спокойно живет в ValueObject из слоя домена.. другое дело если вам нужны ваши любимые хелперы.. тут уж медицина бессильна.. Протечка доменов? Че? Протечка слоев ок.. для этого как раз это все.. но у домена есть контекст и в рамках контекста ему все равно кто его юзает логики там нет, только поведение.. хотя для MVCшников особенно начитавшихся про анемичную модель где ж ей еще быть ))
Здравствуйте, ваша точка зрения мне показалась очень интересной. Могли бы вы порекомендовать какие нибудь материалы которые бы более подробно раскрыли вашу концепцию.