Service Classes in Laravel

One of the most common debates in the Laravel community: where does business logic belong? Controllers get bloated. Models turn into god objects. Actions, services, repositories - everyone has a pattern they swear by.

I've been using service classes for years, and this Laracasts video frames the decision exactly the way I think about it: should you use big models or services?

The problem with fat models

The "fat model, thin controller" advice has been around for a long time. And it works - up to a point. A User model handling authentication, profile updates, subscription management, notification preferences, and team invitations becomes unreadable fast. When a model reaches 500+ lines, something needs to change.

What service classes actually do

A service class groups related business logic that involves one or more models. It's a plain PHP class - no interface, no abstract base class, no framework magic. You inject it where you need it and call descriptive methods.

For example, instead of putting order processing logic in an Order model or a CheckoutController, you create an OrderService that handles calculating totals, applying discounts, processing payment, and sending confirmation emails. The controller calls one method. The model stays focused on data and relationships.

My rules for service classes

A few rules I stick to. Each service covers one domain - OrderService handles orders, SubscriptionService handles subscriptions - and if one starts reaching into unrelated things, I split it. The dependency points one way only: services call models, never the reverse, so models stay unaware that services exist. I keep them easy to test by injecting dependencies through the constructor and avoiding static calls inside the methods, which means I can mock what I need and test the logic on its own. And I don't reach for a service when there's nothing to coordinate - if a controller just validates input and creates a model, that's fine as it is. Services earn their place once there are multiple models or an external API in the mix.

Services vs. actions

Laravel Actions (single-purpose invokable classes) are another popular approach. The difference is granularity: an action does one thing, a service groups related operations. I use both - actions for single operations that get reused across contexts (like CreateInvoicePdf), and services for domain workflows that combine multiple steps.

There's no single right answer. The goal is code that's readable six months from now. Service classes have consistently delivered that for me across projects of all sizes.