Where to place the business logic of a laravel application?

Question

Software design

Hello colleagues.
I have a more general question that I encountered while developing an application.
Where should the business logic of the application be placed?
I have read various articles and they all disagree. Some write that in models, following the principle of "thin" controllers, others write that models are only responsible for working with database fields.
For example, in my project (online store) there is a product filter. Here it is used (so far) only in the category controller, it works only with product and parameter tables. I have separated the filter class into a separate directory called Filters (yes, there are several different ones).
Question:
1. How well did I do (and is it right at all)?
2. Still, where to put such moments of business logic?
Thanks in advance for your replies!
Have a nice and productive day everyone!

Answer 1

My opinion is that in models there should be logic only related to obtaining data from the database. Business logic is written in separate service classes, like yours, for example, the filter class.
Otherwise, the model will grow to thousands of lines of code, and be a hodgepodge of methods. The principle of a class in any OOP is a narrow specialization on one task. The task of the model is to receive data from the database, and write it there.
The controller is just a controller that accepts a request, processes it, pulls the necessary application methods, and gives a response. There is no need to write complex logic in it.

Answer 2

The original idea of ​​MVP was this: the
View was supposed to be a data view, a stupid view that just looked at the changes in the Model fields and updated the view for the user The
Controller was supposed to be responsible for input and output of information to the user. No business logic - just commands and responses.
The Model was supposed to be a representation of the data. This does not mean that models should be "fat" - it means that there should be other parts of the application that are responsible for business logic. Not a model. And certainly not the "model", tightly connected with the database.
And now my IMHO:
1. Controllers accept a request, validate, get an authorized user, check permissions. They call ONE method of some class, format the result and return it.
2. In models, only database logic. No business logic from the word "absolutely". No dependencies. Nothing.
Take out all the logic somewhere. Logic should not know that this is HTTP - i.e. no HTTP request objects, no HTTP responses, no HTTP errors. If 404 is needed, an exception is created for the user case (of the UserNotFoundException type), and it is caught in the controller and converted into NotFoundHttpException. No other way.