Clean Architecture подобно религии все трактует его по разному, на видео один из трактов можно сказать
@Leksgit
Жыл бұрын
Очень хороший вопрос был 19:57 - зачем там laravel? И ответа на этот вопрос не было. С таким же успехом проще использовать lumen. 2 месяца на только понимания архитектуры и подхода... интересно, кто то считает финансовую обоснованность таких подходов, или исключительно подход - мы знаем крутые современные решения которые дадут в перспективе 5 лет профи, при условии переезда на новый фремворк. А то что за это время поменяется несколько раз бизнес процесс...
@АндрейМелентьев-щ1ч
Жыл бұрын
Я бы даже спросил по другому, а зачем там это все "чистое". В целом получается не чистая архитектура, а сложная архитектура, так как чтобы за онбордить в это все нового человека который по какой-то причине не знает что такое "чистая" архитектура уйдет миллион времени. В Laravel и так все сделано таким образом чтобы ты делал максимально понятную архитектуру, единственное что я добавляю слой сервисов и ДТО, но это варьируется от сложности и размера проекта.
@ev_geniy17
Жыл бұрын
@@АндрейМелентьев-щ1ч Он несколько раз повторил что это только для больших проектов. В том то и дело что ларавел не диктует никаких правил как делать правильно, слой сервисов в итоге разрастается в такой ком, что становиться в принципе невозможно его использовать не сломав приложение в другом месте, а оставив бизнес логику в другом месте методы достигают тысячей строк кода. Чистая архитектура диктует определенные правила движения данных и зависимостей, поняв их один раз ты легко читаешь чужой код написанный в этом стиле и чувстуешь себя более уверено изменяя или добавляя логику.
@РомаПостников-ъ6е
Жыл бұрын
@@АндрейМелентьев-щ1ч Я видел проекты, которые писали такие разработчики как вы, контролеры в 2 тысячи строк😢 Зачем вам ООП, если вы только наследование используете от туда? И солид же дебилы придумали, да?
@АндрейМелентьев-щ1ч
Жыл бұрын
@@РомаПостников-ъ6е Не понимаю с чего вы взяли что знаете как я пишу код. Просто нужно понимать что использование чего либо должно быть оправданным, я не говорю что solid не нужен я как раз считаю что он нужен, но только в действительно больших или хотя бы средних проектах. Да бизнес логику надо выносить в отдельный слой, опять же сильно зависит от величины проекта. Мне не нравиться когда начинают игнорировать фреймворк и поверх него писать какие-то не очень адекватные структуры по размеру и сложности это не есть хорошо.
@iteospace
Ай бұрын
На языке на котором нет пакетов сложно проверять что у тебя нет лишних зависимостей. У нас схема такая, есть проекты (каждый проект это отдельный пакет) Domain Interfaces (Repositories, Services, Params, Models) ссылается на Domain Services (Сервисы с бизнес логикой) ссылаются на Domain, Interfaces Models(модели выходные Rest с док. Swagger) Persistance(Репозитории, конфигурация Entity) ссылается на Interfaces Rest(входные модели с валидацией, контроллеры) ссылается на всё так как собирает всё Dependency Injection. Tests(проект с тестами и всем что нужно для тестов)
@MegaPushTV
Жыл бұрын
А можно ссылку на гид проекта, чтоб более подробно изучить, спасибо!
@FlagStudio
Жыл бұрын
а вот, пожалуйста: github.com/OmgProsto/santa-clean
@MegaPushTV
Жыл бұрын
@@FlagStudio оу... огромное вас спасибо!!!!
@MegaPushTV
Жыл бұрын
@@FlagStudio если конечно можно.... не могли бы вы дать контакт человека который на видео, я хотел бы задать пару, а может и нет) вопросов касаемо как то или иное должно быть, еще раз спасибо!
@FlagStudio
Жыл бұрын
можешь написать их пачкой сюда, а мы пригласим Романа ответить на них
@MegaPushTV
Жыл бұрын
@@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. Других пока не могу вспомнить, наверно потому что этот самый главный, и я не могу найти не него ответов
@DenisCepesh
3 ай бұрын
Я правильно понимаю что в файле SantaBuilder.php никаких ларавел хелперов и прочего быть не должно, только "голый" php ?
@kekivanovich9222
3 ай бұрын
только чистое ООП на пхп
@ivanwizard9751
Жыл бұрын
Не понятно как вы избавились от ActiveRecord, если он используется в Repository
@РомаПостников-ъ6е
Жыл бұрын
Я маплю модель ларавеля, на свои - доменные, никто не мешает использовать чистые sql запросы и использовать в репозиториях массивы, также мапить их на доменные сущности
@im_fredy
10 ай бұрын
Я не знаю, о каких больших проектах идет речь.... У нас зарубежный проект 100 - 300к запросов в час (среднем 1.5к юзеров в час ) в зависимости от часа пика. Архитектура Laravel сделана таким образом , что на ней можно крутить все в любых позах и как хочешь. В Контроллере максимум 5 строчек кода. Для дублирования и разрастания кода с успехом выносится все в трейты, сервисы и микро контроллеры. Про базу он вообще бред говорит, у нас на проекте 3 базы (на разных языках )+ несколько баз очередей включая на Go и с, для прослоек которые включаются в часы пик. Но это все слова. У меня несколько вопросов по факту: 1) Какая нагрузка проекта в час? 2) Сколько памяти проект потребляет на каждую тысячу запросов на архитектуре которую демонстрировали и на классической архитектуре? 3) Мы так и не увидели тесты скорости работы этой архитектуры в сравнении с классической? 4) Зачем использовать Laravel в данной архитектуре , если быстрее будет использовать чистый код? ( иначе нужно убрать 70% модулей фреймворка, которые тянутся паровозом и нагружают дополнительно проект) 5)Как считалась экономическая модель данного проекта если штат растет логарифмически? (то есть проект быстро развивается) 6)Покажите мне этого олуха, который скажет что архитектура Laravel сложна в тестировании? Это один из самых лучших фреймворков для тестирования, проще я даже и не вспомню. П,С очень много слов, мы так и не увидели микро примера из реальной логики этого проекта.про легкость тестирования мы услышали, но профуф не увидели. Вообщем мое мнение это просто пустой треп людей, у которых не хватает скила писать чистый код на Laravel. По поводу серверов я так и не понял очем речь? Сейчас 99% хайлоад проектов собирается из слепка на amazon с динамическим разбиением нагрузки на разные машины для стабильной + резервной работы и низкого пинга вне зависимости от числа пользователей. (кроме китайских сервисов) В мире нет аналогов по мощьности и стабильности, я думаю это все прекрасно знают. Я думаю данный подход и такие костыли сделаны для того, что бы заказчик при желании не смог поменять команду разработчкив и полностью от нее зависил, т.к поменять команду будет дороже, чем писать заново.
@РомаПостников-ъ6е
8 ай бұрын
Хах, надеюсь вы еще не сошли с ума, вынося все в трейты) Из-за таких разработчиков как вы многие считают php умершим языком, все большие проекты пишутся по чистой архитектуре + DDD. Вы упомянули Go, но 90 процентов проектов на Go пишутся на чистой архитектуре, тинькоф, авито, озон и другие гиганты it-индустрии используют чистую архитектуру, а вы и дальше сидите в своей веб - студии и пилите интернет магазины на MVC структуре
@РомаПостников-ъ6е
8 ай бұрын
По докладу, без вопросов, есть недочеты, да, можно было показать тестирования и чуть получше раскрыть пример из реальной логики. Но то что вы говорите, что чистая архитектура - это бред, говорит только о вашем узком мышлении и то что вы не принимаете общеизвестные факты, как вредный дед
@im_fredy
8 ай бұрын
@@РомаПостников-ъ6еу моей команды 248 комитов на гите по проектам ларавел, мы прекрасно понимаем структуру и назначения каждой строчки. Когда мы обсуждаем вектор развития с Тэйлором, он прекрасно дал понять, что все развитие и дальнейшее использование должно быть векторно с доктринной. Я не знаю на каких знаниях основан ваш комментарий. Чистая архитектура на ларавел = это не ларавел. Laravel это доктрина. Можно взять пакеты и собрать все что угодно, но это не будет ларавел и он для этого не предназначен.Прочитайте хотя бы 1 раз доктрину ларавел , потом выпейте таблетки , которые прописал ваш психиатр, подумайте и напишите осмысленно. Резюмируя, зайдите в любой фреймворк и посмотрите что он есть.
@ejoys3
5 ай бұрын
Вы из 2005-го? В современной разработке ваши показатели нагрузок, производительности и прочего не имеют никакого значения вообще! Все это решается давно железом, некоторым даже проще через балансировщик еще пару серверов поднять чем профилировать запрос к БД и подбирать индексы.. Железо стоит копейки, дорого стоит разработка и поддержка и это единственное что всем движет.
@im_fredy
5 ай бұрын
@@ejoys3 вы правы, только для маленьких проектах
@АнтонЧалый-щ4х
Жыл бұрын
Особенно понравилась фраза "Делают одну и ту же задачу..." (kzitem.info/news/bejne/k5Cnv5x7n3iqopg). Я уже представляю лицо заказчика )))
@FlagStudio
Жыл бұрын
😂😂😂
@АртемАртеменконезабывайвыходит
Жыл бұрын
сделайте видео как делать мульти язычные теги и мульти язычные страны регионы города например пользоатель выбирает Берлин и в зависимсоти от того на каком языке он пишет подсвечивает нужный город а в поиске Berlin Берлин или другие языки роли не играет
@fitter2boss72
6 ай бұрын
Для такой небольшой задачи, гит можно было и выложить.
@mirosh1257
Жыл бұрын
02:04 грубая ошибка в диаграмме, моделька никогда не отправляет в View, этим занимается только контроллер И вообще в коробке laravel не MVC, а MVCR. Тоесть в ларке роуты является отдельным компонентом, если сравнивать с symfony то внутри контроллера указывается роуты через аннотации или атрибут.
@РомаПостников-о7о
Жыл бұрын
Эта схема не для того чтобы показать течение данных, она просто показывается что все связано, она не несет никакого смысла в себе
@SemyonF89
8 ай бұрын
Отвязаться от фрейворка, чтобы привязаться к другому. Заказчик всё оплатит, чо. Больше золота
@ejoys3
5 ай бұрын
Мда.. такое ощущение что видосу лет 10.. так все жиденько.. Ларка очевидно не для того чтобы ее там выпиливать, а для реализации слоя инфраструктуры.. хотя Laravel, Symfony, Yii2 это такой же легаси как и Zend которые зиждиться на плечах адептов которые не понимают зачем на самом деле composer.. И в доменный слой можно затянуть вендора.. тот же вендоровский uuid спокойно живет в ValueObject из слоя домена.. другое дело если вам нужны ваши любимые хелперы.. тут уж медицина бессильна.. Протечка доменов? Че? Протечка слоев ок.. для этого как раз это все.. но у домена есть контекст и в рамках контекста ему все равно кто его юзает логики там нет, только поведение.. хотя для MVCшников особенно начитавшихся про анемичную модель где ж ей еще быть ))
@newparadigma6637
3 ай бұрын
Здравствуйте, ваша точка зрения мне показалась очень интересной. Могли бы вы порекомендовать какие нибудь материалы которые бы более подробно раскрыли вашу концепцию.
@timbl4189
Жыл бұрын
Всегда было непонятно, как валидировать данные в чистой архитектуре? Куда вставить валидацию, если она сложная? Например, валидация зависит от нескольких других моделей, юзера, статусов, и т.п.
@РомаПостников-о7о
Жыл бұрын
Отличный вопрос, у нас тоже было много дискуссий на эту тему. Пришли к выводу, что можно это делать в UseCase-ах, также вызывая интерфейсы. Но есть вариант, прямо в FormRequest, тоже вызывая интерфейсы, но это немного неправильно, таким же успехом можно доменные интерфейсы вызывать из контроллера, но это не так(
Пікірлер: 38