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

One domain per service. An OrderService handles orders. A SubscriptionService handles subscriptions. If a service is doing too many unrelated things, split it.

Services call models, not the other way around. Models shouldn't know about services. Services orchestrate models.

Keep them testable. Inject dependencies through the constructor. Avoid static calls inside service methods. This makes unit testing straightforward - you can mock the dependencies and test the logic in isolation.

Don't create a service for simple CRUD. If a controller just validates input and creates a model, that's fine as-is. Services earn their place when there's coordination between multiple models or external APIs.

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.