Я бы даже спросил по другому, а зачем там это все "чистое". В целом получается не чистая архитектура, а сложная архитектура, так как чтобы за онбордить в это все нового человека который по какой-то причине не знает что такое "чистая" архитектура уйдет миллион времени. В Laravel и так все сделано таким образом чтобы ты делал максимально понятную архитектуру, единственное что я добавляю слой сервисов и ДТО, но это варьируется от сложности и размера проекта.

@@user-xf5dz5go9v Он несколько раз повторил что это только для больших проектов. В том то и дело что ларавел не диктует никаких правил как делать правильно, слой сервисов в итоге разрастается в такой ком, что становиться в принципе невозможно его использовать не сломав приложение в другом месте, а оставив бизнес логику в другом месте методы достигают тысячей строк кода. Чистая архитектура диктует определенные правила движения данных и зависимостей, поняв их один раз ты легко читаешь чужой код написанный в этом стиле и чувстуешь себя более уверено изменяя или добавляя логику.

@@user-xf5dz5go9v Я видел проекты, которые писали такие разработчики как вы, контролеры в 2 тысячи строк😢 Зачем вам ООП, если вы только наследование используете от туда? И солид же дебилы придумали, да?

@@user-dk1id8nn4o Не понимаю с чего вы взяли что знаете как я пишу код. Просто нужно понимать что использование чего либо должно быть оправданным, я не говорю что solid не нужен я как раз считаю что он нужен, но только в действительно больших или хотя бы средних проектах. Да бизнес логику надо выносить в отдельный слой, опять же сильно зависит от величины проекта. Мне не нравиться когда начинают игнорировать фреймворк и поверх него писать какие-то не очень адекватные структуры по размеру и сложности это не есть хорошо.

только чистое ООП на пхп

😂😂😂

а вот, пожалуйста: 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. Других пока не могу вспомнить, наверно потому что этот самый главный, и я не могу найти не него ответов

Я маплю модель ларавеля, на свои - доменные, никто не мешает использовать чистые sql запросы и использовать в репозиториях массивы, также мапить их на доменные сущности

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

Хах, надеюсь вы еще не сошли с ума, вынося все в трейты) Из-за таких разработчиков как вы многие считают php умершим языком, все большие проекты пишутся по чистой архитектуре + DDD. Вы упомянули Go, но 90 процентов проектов на Go пишутся на чистой архитектуре, тинькоф, авито, озон и другие гиганты it-индустрии используют чистую архитектуру, а вы и дальше сидите в своей веб - студии и пилите интернет магазины на MVC структуре

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

@@user-dk1id8nn4oу моей команды 248 комитов на гите по проектам ларавел, мы прекрасно понимаем структуру и назначения каждой строчки. Когда мы обсуждаем вектор развития с Тэйлором, он прекрасно дал понять, что все развитие и дальнейшее использование должно быть векторно с доктринной. Я не знаю на каких знаниях основан ваш комментарий. Чистая архитектура на ларавел = это не ларавел. Laravel это доктрина. Можно взять пакеты и собрать все что угодно, но это не будет ларавел и он для этого не предназначен.Прочитайте хотя бы 1 раз доктрину ларавел , потом выпейте таблетки , которые прописал ваш психиатр, подумайте и напишите осмысленно. Резюмируя, зайдите в любой фреймворк и посмотрите что он есть.

Вы из 2005-го? В современной разработке ваши показатели нагрузок, производительности и прочего не имеют никакого значения вообще! Все это решается давно железом, некоторым даже проще через балансировщик еще пару серверов поднять чем профилировать запрос к БД и подбирать индексы.. Железо стоит копейки, дорого стоит разработка и поддержка и это единственное что всем движет.

@@ejoys3 вы правы, только для маленьких проектах

Эта схема не для того чтобы показать течение данных, она просто показывается что все связано, она не несет никакого смысла в себе

Здравствуйте, ваша точка зрения мне показалась очень интересной. Могли бы вы порекомендовать какие нибудь материалы которые бы более подробно раскрыли вашу концепцию.