Multiple models for User provider?

Question

Laravel

The problem is the following - I have a standard user model, it contains such functionality as roles, restrictions, different getAttribute, setAttribute, etc. As the project grows, different functionality and different connections are added to the user. For example, the user can interact with books, with companies, and so on. All this functionality clogs the main model App\User. At first, I decided to put the code for each functionality into separate traits, i.e. if this is the functionality of working with a company, then all connections and methods for interacting with them are in the trait App\Company\UserCompanyTrait, for books it is App\Library\UserBooksTrait, etc. But I didn’t really like this idea and I decided to split it into classes, inheriting the base App\User. This is where the main problem appeared - in order to use the method to get the current userAuth::user()the user class must be explicitly specified in the authorization configuration file config/auth.php -- providers.users.model. Actually, the question itself is how can one specify either several models for the same provider, or a basic user model so that it is possible to use several classes?

Answer 1

All this functionality pollutes the main App\User model

So can remove it from the user? For example, a user-company relationship can be one-way (and ideally should be). The less entities know about other entities, the easier it is to live.
This is a kind of self-deception, because you still have too fat classes. And they come out because they know too much.
Table inheritance. In this case, the provider will continue to work with the User, and what subtype instance will be spit out - these are details.

Answer 2

As the project grows, different functionality and different connections are added to the user. For example, the user can interact with books, with companies, and so on.

most likely you need an abstraction layer to work with models, services are usually suitable for this

Answer 3

It is better not to use inheritance, to create models responsible only for domain logic, if necessary, you can link them through a 1-1 relationship.