Правильное видение архитектура масштабируемого приложения на laravel?

Question

[Denis]

Вопрос к более знающим людям

Если у меня планируется большое приложение с множеством разной бизнес логики имеет ли смысл разбивать файлики сервисов не просто в отдельную папку "Services", а полноценно создавать отдельный каталог "User/Services" и так же для других более глобальных сервисов, к примеру "Product/Services" и "Product/Controller" т.д.

И насколько правильно было бы создавать в каждом таком каталоге "Product" или "User" свой каталог "Model" с обращением в одну и туже таблицу в бд? К примеру у "Product/Model/User" имеется модель к обращению в таблицу "user" и у "User/Model/User" так же имеется модель к обращению в таблицу "user" просто со своими отношениями и правилами.

Насколько это хороший подход в масштабируемых приложениям?

Comments

[Дмитрий]

https://stitcher.io/blog/laravel-beyond-crud-01-do...

[Алан Гибизов]

Обратите внимание на п.3.6

Answer 1

[Sanes]

Если много отношений, то просто выносите их в трейты. Сможете их переиспользовать.

app/Traits/Relations/BelongsToUser.php
app/Traits/Relations/HasManyPoducts/php

и т.д.

Answer 2

[Вячеслав Плиско]

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