Laravel/Lumen Best Practice for huge application business logic

First thing is to stop using Lumen and use Laravel. Lumen is probably going to die in the following period.

Create classes (option 2) but in Laravel, they are more referred to as action classes. Make sure that those classes only serve one purpose. A common location to store them is the App\Actions namespace or app/Actions directory.

@engrlaravel The first step is to simplify your logic as much as possible. Just because a business process is complicated, doesn’t mean your code has to be.

As @bugsysha says, you’re free to create your own classes. So if you want to create service classes to hold business logic, you can do so. If you want to create action classes, then you can do that too.

Repositories are an awful design pattern though because I’ve never seen them implemented properly, and people just try and re-implement Eloquent in them and just end up with classes that are a mess and nowhere near as powerful as Eloquent. If you’re using Lumen or Laravel, then there’s a 99.9% chance you’ll be using Eloquent.

Finally yes, use Laravel instead of Lumen. Even for API-only projects. Lumen really offers nothing these days, and Laravel has lots of features that make API development easier that even Lumen doesn’t have. Things like form requests, route–model binding, Eloquent API resources, Passport and Sanctum for authorisation, etc. The last company I worked at, they were converting their massive e-commerce platform to a REST API and started on Lumen, and eventually convinced them to just re-platform to Laravel since they kept back-porting features from it and were using Passport.