Service vs Repository pattern: time to end the debate
Every month there is a new thread asking whether to use Repository pattern in Laravel. My experience after working on six different Laravel projects.
Short answer: Repository pattern adds overhead that is rarely justified in a Laravel/Eloquent project. Service classes are enough.
Agree. The Repository pattern makes sense when your data layer is interchangeable or you need to test without a DB. In practice Laravel projects do not switch ORMs and Eloquent models can be tested with SQLite in-memory just fine. The extra abstraction layer adds files without adding value.
Repository pattern comes from DDD and is valuable if you are applying DDD principles consistently. In a typical CRUD Laravel app it is just ceremony. Use it if you are doing DDD. Skip it otherwise.
We used repository pattern on a large project and it became a maintenance burden. Every new feature needed changes in three layers. Now we use service classes and call Eloquent directly. Code is half the size.
The testability argument was stronger before Eloquent factories and the Database::fake() helpers. Now you can test Eloquent models with minimal setup. The “hard to test without repository” reasoning no longer holds.
What do you put in service classes? Full business logic including validation, or just orchestration between models?
Business logic, authorization, and orchestration between multiple models. Validation stays in Form Request classes. DB queries stay in the service or model scopes. No thin services that just proxy model calls.
```php blocks are runnable.