Задать вопрос
another_dream
@another_dream
Backend-разработчик, Laravel/ZF2/Yii2

Как правильно спроектировать Laravel приложение с уклоном в enterprise?

Планируем начинать новый проект и хотелось бы организовать структуру с учётом лучших практик.
Если кто-либо сможет предоставить реальный пример разделения приложения на слои (DDD) - буду искренне благодарен.

Предполагаю, что необходимо разделить приложение (app/) на Laravel-specific логику (контроллеры, мидлвари и прочее), Domain (интерфейсы, имплементации репозиториев):

А как Вы проектируете свои приложения?

Спасибо.
  • Вопрос задан
  • 7390 просмотров
Подписаться 34 Оценить Комментировать
Пригласить эксперта
Ответы на вопрос 6
@Finsh
Взять Symfony.
Только вот серьёзно, зачем делать из отвертки дрель, когда она уже есть. Вы думаете, что это будет быстрее? Вы думаете что это будет дешевле? Laravel прекрасен для своих, средних, задач, для "enterprise" берите Symfony.
Ответ написан
Комментировать
AmdY
@AmdY
PHP и прочие вебштучки
Главное правило счастливого энтерпрайза - не тащить методики и технологии в которых нет опыта. Если вы не работали на проектах с DDD, не делали своих пет проектов чтобы опробовать подход, то не надо тренироваться на больших проектах.
Я уже 10 проектов в мире симфони видел и с тремя работал, везде попытки сделать DDD заканчивались невероятной сложностью поддержки после которой даже битрикс не кажется ужасом. 4 дня и изменения в 32 файлах чтобы добавить в список сортировку и фильтрацию... Наверное, можно писать на DDD правильно и с быстрой разработкой и лёгкой поддержкой, но я ещё таких проектов ни сам не создавал, не работал с чужими, не видел в качестве примеров. Поддерживать 10 летний легаси стартанутый на php4 с глобальными переменными гораздо проще чем любую поделку ddd-шников.
Ответ написан
Комментировать
SowingSadness
@SowingSadness
web-разработчик
Сейчас напишу немного высокомерно, но опыт позволяет. Уже почти 20 лет в разработке и около 15 в веб.
Надо понимать, что почти все кто используют многочисленные Фреймворки не понимают что такое ООП. А уж тем более, что такое SOLID и т.д.
И поэтому, что бы они не писали, в конце-концов превращается в какашку с костылями.
Да, потом героически проект переписывается с учётом изменений (или ещё чаще умирает) Но, он по прежнему остаётся абсолютно не расширяемым и не поддерживаемым.

И вот мы возвращаемся к Фреймворкам.
Нужно брать тот Фреймворк, который писали с учётом определённых парадигм и принципов. Так как этих вот парадигм, достаточно описанных и изученных не так много (на самом деле их 2.5 штуки), то можно сразу ориентироваться на ООП + MVC(или MVP или MVVM) + SOLID
Если Фреймворк что-то из этого нарушает, то он по умолчанию не может вам дать возможность написать хорошее, расширяемое приложение. А хороший Фреймворк, даже начинающим программистам должен прививать правильные подходы к разработке. Что-бы хочешь, не хочешь, а hello world уже не превращался в ад.

Сразу оговорюсь, что я давно "забил" на Фреймворки. Есть один идеальный — это Pyramid. А оцениваю любой продукт по документации. Там сразу видны все огрехи и косяки. Буду писать и параллельно смотреть в доки.

Larvel
Первое что я вижу в этом Фреймворке, что большая часть работы каркасных компонентов завязана на статических вызовах. На этом можно уже, даже и остановиться. ООП, по большому счёту тут нет. Суть ООП в использовании объектов. Тут же класс выступает в качестве пространства имён функций.
Раз нет ООП, то и нет всей теории и принципов связанных с ним.
А раз под этим Фреймворком не заложено никакой теории, то в 99% случаев можно сказать, что на нём что-то правильно, написать невозможно.

Если взглянуть глубже, то открывается ещё больше ада:
ActiveRecord.
Плох по умолчанию. С ним очень тяжело контроллировать целостность данных. Вам нужно придумать слой абстракции, где вы будете транзакционно записывать все данные вне бизнес логики. Фреймворк вам тут не поможет. Он предложит это делать в экшене (контроллере). И тут вы столкнётесь, что при написании чего-то сложнее чем бложик, вы будете терять целостность. Ибо бизнес логика и работа БД будет в одном методе. Отладка будет усложняться, ошибок плодиться и т.д.
И не зависит это от программистов. Шаблон сам по себе провоцирует ошибаться.
Далеко за примерами ходить не нужно, уже треш.

Чем больше примеров я смотрю, тем больше не понимаю, как все это дело расширять. Как вставлять прозрачно через весь проект свои собственные аспекстные решения. Например RBAC. Или, если нужно, логику работы приложения отделить от БД и когда нужно, подставлять необходимую реализацию.
Или сделать работу всех экшенов в рамках клиента, но производить авторизацию по пользователю(сотруднику)

Все это предлагается зашивать прям в контроллерах, с помощью protected или private методов.
Повеситься. Сложность приложения зашкалит.

Symfony
Только при выходе 2 версии я работал с этим чудом. Разработчики писали его под хапйом dependency injection. Мало того, что они взяли не самую хорошую стратегию для реализации всего костяка фреймворка, так ещё и сделали её не правильно.
Они написали универсальный DI Container и кладут в него все что угодно, используя в качестве идентификатора строчку.
Строчку, М**Ь ЕЁ! Не интерфейс — строчку!
И знаете чем это аукнется? А тем, что при разработке своего приложения или очередного бандла, вам будет говорить, что в контейнере лежит что-то не то и вы подохните в конфигурационных настройках. А все потому что, подход: ВСЁ через DIC — строго навязывается.
Расширение этого чуда, тоже причинит вам массу головной боли. Ведь, зачастую, вы будете работать с классами, которые ждут не интерфейс, а что-то из контейнера с ключём "я_твой_дом_шатал".

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

Но, по правде говоря, слепить что-то годное возможность есть.
Если взять микро ядро symfony, прикрутить Doctrine, то получится что-то годное.
Но встаёт вопрос. А зачем вообще symfony, если можно взять doctrine и написать все остальное свое?
И тут вы окажетесь правы — незачем.

Ситуация с Symfony в enterprise очень схожа с ситуацией с Django. Повидал уже с десяток проектов, где последнюю брали для больших приложений. В итоге от Django оставались рожки да ножки. Всю её переписывали.
Спрашивается — и зачем? Просто потратили кучу времени.

Так что, если нужен суровый enterprise. Что бы писать что-то большое, с возможностью расширения — берите Pyramid и переходите на python.
Ничего, даже близко с пирамидкой, по возможностью расширения, даже близко не лежало.
Ответ написан
index0h
@index0h
PHP, Golang. https://github.com/index0h
Комментировать
@zugo
Из личного опыта, вкратце:
1. Не используйте фасады, только dependency injection, благо автоматическое разрешение зависимостей в Laravel очень мощное и удобное.
2. Не используйте Eloquent, используйте Doctrine. *
3. Не стесняйтесь использовать асинхронные задачи. При желании можно с их помощью реализовать полноценный CQRS.

* - Если, конечно, в вашем представлении сущность бизнес-логики соответствует модели ORM, ведь DDD предполагает разделение "domain layer" от "persistence layer", хотя Doctrine ползволяет довольно безболезненно их смешивать. В любом случае, Eloquent - худшая часть Laravel, и, наверное, одна из самых неудачных реализаций ActiveRecord на PHP.
Ответ написан
Используйте Laravel и не беспокойтесь. Он построен на Symfony. Если понадобится, то использование Doctrine вместо/вместе с Eloquent возможно.

Вы дольше будете изучать Symfony и набирать команду с его поддержкой. Проще использовать его части, а не строить из себя умного сноба, оправдывающего высокую зарплату.

Laravel позволит быстро построить прототип. Изменить какие-то критичные части всё одно придётся. И это не отменит использование частей от Symfony.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы