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

Question

[vitaly_74]

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

Comments

[vitaly_74]

Все это применимо конечно к другому фреймворку, но сейчас дело касается laravel

Answer 1

[Евгений Ромашкан]

Что вы подразумеваете под пакетами?

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

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

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

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

но стандарт MVC

MVC это не стандарт и ничего общего эта аббревиатура со структурой папок не имеет

Comments

[vitaly_74]

я же не говорю что в этих 3х папках будет весь проект например будет пакет cabinet в нем будет бизнес логика, в виде моделей, пару контроллеров, и виды которые относятся к кабинету. всё. будут другие пакеты, которые будут выполнены точно также. если проще пакет - это есть модуль, который использует не много зависимостей самой системы. (база данные общие функции), но пакеты не могут быть зависимы друг от друга.

[Евгений Ромашкан]

vitaly_74, Абсолютно нормальная практика, только количество зависимостей нужно минимизировать между пакетами, но они будут.
Выносить весь код от которого зависит более одного пакета в отдельную общую папку так себе идея, потому что в итоге у вас в приложении будет один огромный пакет(эдакий Common/Core/Shared или что-то подобное) от которого зависят все

[vitaly_74]

Евгений Ромашкан, вы меня поняли!) а как решить такую проблему - одного огромного ресурса (например у меня будет 50 моделей для связи с 50 таблицами в бд), но нужно обязательно понимать что логики в них вообще не будет. заносить их в соотвтетсвующие модули - точно нельзя.

[Евгений Ромашкан]

vitaly_74,

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

Т.е. у вас есть множество данных которые пользователи системы могут заполнять/сохранять/просматривать, но в системе нету Бизнес-логики которая зависит от этих данных, нету смысла деражать их там же где лежит логика?

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

Необычная ситуация если там прям 50 моделей, возможно их все можно в единый модуль вынести. Это, опять же, не станет проблемой если логики там нету.

[vitaly_74]

Благодарю вас за ответ.

Answer 2

[Евгений Вольф]

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

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

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

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

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

"Не гадить в код" - это искусство и опыт, которые никакой "пакет" не заменит.

Comments

[vitaly_74]

Благодарю вас за ответ.

Answer 3

[gian_tiaga]

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

Comments

[dmitriy]

так вы не делайте зависимыми

[vitaly_74]

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

[gian_tiaga]

dmitriy, простейший пример есть Посты, есть Новости, есть Юзеры, есть Комментарии. У юзера есть комменты и он может быть автором и новости и поста. Комменты относятся как к постам так и к новостям, соответсестенно эти оба имеют автора из юзеров.
А теперь расскажите как разнести это на независимые модули?

[dmitriy]

если пакеты и модули одно и тоже то в моем понимании это контекст, например Контент, или Блог.
Соответственно в этом контексте-пакете будет логика работы с постами и новостями, юзеры и комменты. Думаю что вас смущает что этот же юзер будет использоваться в другом пакете, например в пакете авторизации/аутентификации.
так вам необязательно хранить в пакете реализацию вашей модели.
например там можно будет встретить как AuthorInterface, PostInterface,CommentInterface
например сервис получения статьи
class PostService
public function getById(): PostInterface {

где у сущности PostInterface в свою очередь будет
public function getAuthor(): AuthorInterface;

потом у вас будет папка для инфраструктурного кода там будут ваши реализации интерфейсов, созданных с помощью фраймворка
class UserModel impliments AuthorInterface, UserInterface

вообще много статей и практик, последняя хорошая https://habr.com/ru/company/ispring/blog/560074/

Answer 4

[dmitriy]

Названия пакетов?