LARAVEL + Clean Architecture // Роман Постников
HTML-код
- Опубликовано: 4 окт 2024
- В этом видео Роман поделится главным принципом «Чистой архитектуры», и расскажет как вынести весь фреймворк на внешний слой, от которого не будет зависеть бизнес-логика приложения. Такое решение поможет легко тестировать и поддерживать даже самое большое приложение
Изучайте Git на практике: gogit.ru/
Подписывайтесь на наш канал в Телеграм: t.me/flagstudio
ВК: flagstudio
Instagram: / thisisflagbaby
Clean Architecture подобно религии все трактует его по разному, на видео один из трактов можно сказать
Очень хороший вопрос был 19:57 - зачем там laravel? И ответа на этот вопрос не было. С таким же успехом проще использовать lumen. 2 месяца на только понимания архитектуры и подхода... интересно, кто то считает финансовую обоснованность таких подходов, или исключительно подход - мы знаем крутые современные решения которые дадут в перспективе 5 лет профи, при условии переезда на новый фремворк. А то что за это время поменяется несколько раз бизнес процесс...
Я бы даже спросил по другому, а зачем там это все "чистое". В целом получается не чистая архитектура, а сложная архитектура, так как чтобы за онбордить в это все нового человека который по какой-то причине не знает что такое "чистая" архитектура уйдет миллион времени. В Laravel и так все сделано таким образом чтобы ты делал максимально понятную архитектуру, единственное что я добавляю слой сервисов и ДТО, но это варьируется от сложности и размера проекта.
@@АндрейМелентьев-щ1ч Он несколько раз повторил что это только для больших проектов. В том то и дело что ларавел не диктует никаких правил как делать правильно, слой сервисов в итоге разрастается в такой ком, что становиться в принципе невозможно его использовать не сломав приложение в другом месте, а оставив бизнес логику в другом месте методы достигают тысячей строк кода. Чистая архитектура диктует определенные правила движения данных и зависимостей, поняв их один раз ты легко читаешь чужой код написанный в этом стиле и чувстуешь себя более уверено изменяя или добавляя логику.
@@АндрейМелентьев-щ1ч Я видел проекты, которые писали такие разработчики как вы, контролеры в 2 тысячи строк😢 Зачем вам ООП, если вы только наследование используете от туда? И солид же дебилы придумали, да?
@@РомаПостников-ъ6е Не понимаю с чего вы взяли что знаете как я пишу код. Просто нужно понимать что использование чего либо должно быть оправданным, я не говорю что solid не нужен я как раз считаю что он нужен, но только в действительно больших или хотя бы средних проектах. Да бизнес логику надо выносить в отдельный слой, опять же сильно зависит от величины проекта. Мне не нравиться когда начинают игнорировать фреймворк и поверх него писать какие-то не очень адекватные структуры по размеру и сложности это не есть хорошо.
На языке на котором нет пакетов сложно проверять что у тебя нет лишних зависимостей.
У нас схема такая, есть проекты (каждый проект это отдельный пакет)
Domain
Interfaces (Repositories, Services, Params, Models) ссылается на Domain
Services (Сервисы с бизнес логикой) ссылаются на Domain, Interfaces
Models(модели выходные Rest с док. Swagger)
Persistance(Репозитории, конфигурация Entity) ссылается на Interfaces
Rest(входные модели с валидацией, контроллеры) ссылается на всё так как собирает всё Dependency Injection.
Tests(проект с тестами и всем что нужно для тестов)
Особенно понравилась фраза "Делают одну и ту же задачу..." (ruclips.net/video/2ZqYhEfFyoc/видео.html). Я уже представляю лицо заказчика )))
😂😂😂
А можно ссылку на гид проекта, чтоб более подробно изучить, спасибо!
а вот, пожалуйста: 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. Других пока не могу вспомнить, наверно потому что этот самый главный, и я не могу найти не него ответов
Я правильно понимаю что в файле SantaBuilder.php никаких ларавел хелперов и прочего быть не должно, только "голый" php ?
только чистое ООП на пхп
Не понятно как вы избавились от ActiveRecord, если он используется в Repository
Я маплю модель ларавеля, на свои - доменные, никто не мешает использовать чистые sql запросы и использовать в репозиториях массивы, также мапить их на доменные сущности
сделайте видео как делать мульти язычные теги и мульти язычные страны регионы города например пользоатель выбирает Берлин и в зависимсоти от того на каком языке он пишет подсвечивает нужный город а в поиске Berlin Берлин или другие языки роли не играет
Всегда было непонятно, как валидировать данные в чистой архитектуре? Куда вставить валидацию, если она сложная? Например, валидация зависит от нескольких других моделей, юзера, статусов, и т.п.
Отличный вопрос, у нас тоже было много дискуссий на эту тему. Пришли к выводу, что можно это делать в UseCase-ах, также вызывая интерфейсы. Но есть вариант, прямо в FormRequest, тоже вызывая интерфейсы, но это немного неправильно, таким же успехом можно доменные интерфейсы вызывать из контроллера, но это не так(
Для такой небольшой задачи, гит можно было и выложить.
02:04 грубая ошибка в диаграмме, моделька никогда не отправляет в View, этим занимается только контроллер
И вообще в коробке laravel не MVC, а MVCR. Тоесть в ларке роуты является отдельным компонентом, если сравнивать с symfony то внутри контроллера указывается роуты через аннотации или атрибут.
Эта схема не для того чтобы показать течение данных, она просто показывается что все связано, она не несет никакого смысла в себе
Отвязаться от фрейворка, чтобы привязаться к другому. Заказчик всё оплатит, чо. Больше золота
Мда.. такое ощущение что видосу лет 10.. так все жиденько.. Ларка очевидно не для того чтобы ее там выпиливать, а для реализации слоя инфраструктуры.. хотя Laravel, Symfony, Yii2 это такой же легаси как и Zend которые зиждиться на плечах адептов которые не понимают зачем на самом деле composer.. И в доменный слой можно затянуть вендора.. тот же вендоровский uuid спокойно живет в ValueObject из слоя домена.. другое дело если вам нужны ваши любимые хелперы.. тут уж медицина бессильна.. Протечка доменов? Че? Протечка слоев ок.. для этого как раз это все.. но у домена есть контекст и в рамках контекста ему все равно кто его юзает логики там нет, только поведение.. хотя для MVCшников особенно начитавшихся про анемичную модель где ж ей еще быть ))
Здравствуйте, ваша точка зрения мне показалась очень интересной. Могли бы вы порекомендовать какие нибудь материалы которые бы более подробно раскрыли вашу концепцию.