Плоха ли описанная архитектура, для laravel?

Добрый день. Опишу архитектуру которую хочу сделать я:
весь проект разбить на пакеты (модульная архитектура), и расширять систему в виде пакетов. в каждом пакете может быть своя архитектура (но стандарт MVC) - почему так - если нужно что то исправить то идем в конкретную папку и правим там. не нужно размазывать код, одного большого элемента, по всему фреймворку. Далее все общие ресурсы (модели через которые создаются связи в базе данных. т.е. eloquent) - расположены в какой то общей папке. и доступ к ним имеют все пакеты, в пакетах же спрятана вся бизнес логика, а в общих моделях только подключения к бд, и никакой логики.
Преследую цель максимально сделать систему несвязной.
Чем это хуже подхода - когда вся логика распологается в сервисах, и в целом чем плох такой подход?
  • Вопрос задан
  • 973 просмотра
Решения вопроса 1
@EvgeniiR
https://github.com/EvgeniiR
Что вы подразумеваете под пакетами?

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

То что фреймворк по дефолту генерирует папочки Controller Model View, не значит что обязательно их использовать именно в таком виде. Делите проект на логические модули, выделяйте модули в отдельные папки со своими моделями и контроллерами.
Делать 3 папки-свалки с контроллерами/моделями/видами очень плохая идея в плане навигации контроля связности и зависимостей между модулями
См. Структура проекта

Чем это хуже подхода - когда вся логика распологается в сервисах, и в целом чем плох такой подход?

Логика в сервисах это большая связность чем нормально спроектированная доменная модель.
Про бизнес-логику в сервисах см. Anemic Domain Model

но стандарт MVC

MVC это не стандарт и ничего общего эта аббревиатура со структурой папок не имеет
Ответ написан
Пригласить эксперта
Ответы на вопрос 3
Wolfnsex
@Wolfnsex
Если не хочешь быть первым - не вставай в очередь!
Чем это хуже подхода - когда вся логика распологается в сервисах, и в целом чем плох такой подход?
Он ничем не хуже и не лучше. Пакеты - это одно, сервисы - другое, а Вы их зачем-то "складываете в одну корзину". Что по сути своей представляет пакет? - пакет - это некий модуль, решающий какую-то конкретную задачу, поддерживаемый и обслуживаемый конкретным веднором. В массе своей пакеты никак не привязаны к тому, где и как они будут использоваться. То есть, пакет - это некий набор общей логики, процессов и т.д. для решения какой-то задачи (или набора схожих/связанных задач), например для обработки изображений.

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

Не стоит забывать, что чем более универсальным является какое-то решение (аки "швецарский нож") - тем хуже оно решает конкретную задачу. Это же полностью применимо и к тому, что описываете Вы. Если Вы будете делать некие универсальные решения и складывать их в пакеты:
1. Потеряете выраженность решений
2. Потеряете производительность
3. Получите на обслуживание много приложений (пакетов) вместо одного конкретного

Если же Вы собираетесь складывать в пакеты не "универсальные решения", а "точечные" - то это на мой взгляд худший из возможных вариантов, так как это будет всё то же "размазывание кода", только убранное в другую папку, с глаз долой, плюс к этому добавятся все прелести связанные с обслуживанием пакетов.

"Не гадить в код" - это искусство и опыт, которые никакой "пакет" не заменит.
Ответ написан
@gian_tiaga
На словах модульная архитектура звучит хорошо, но по факту со временем всё сливается в сильно зависимые модули друг от друга, и сложная поддержка. Монолит проще поддерживать. На нескольких проектах пришлось переписывать из за сложности поддержки из модульной в мнолоит.
Ответ написан
Ваш ответ на вопрос

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

Войти через центр авторизации
Похожие вопросы