Every Laravel project has one. The controller method that started as six tidy lines and is now a 90-line scroll of validation, permission checks, database writes, emails and a suspicious if that nobody wants to touch.

Nobody writes it on purpose. It grows one "quick fix" at a time, because the controller is always the nearest place to put code. The good news is that Laravel already gives you the tools to keep controllers thin. The confusing part is knowing which tool takes which job.

The mistake: one method doing five jobs

Here's a typical "renew a lease" method. It's not terrible. That's what makes it dangerous, because it will keep growing:

public function renew(Request $request, Lease $lease)
{
    $data = $request->validate([
        'months' => ['required', 'integer', 'in:6,12,24'],
    ]);

    if ($request->user()->cannot('renew', $lease)) {
        abort(403);
    }

    $renewal = DB::transaction(function () use ($lease, $data) {
        $lease->update(['status' => 'renewed']);

        return $lease->renewals()->create([
            'starts_at' => $lease->ends_at->copy()->addDay(),
            'ends_at' => $lease->ends_at->copy()->addMonths($data['months']),
            'rent' => $lease->rent,
        ]);
    });

    Mail::to($lease->tenant)->queue(new LeaseRenewed($renewal));

    return redirect()->route('leases.show', $lease);
}

Count the jobs: validation, authorization, a business operation, a side effect, and an HTTP response. Only the last one is really the controller's business.

Why it hurts

The pain doesn't show up on day one. It shows up when:

• The mobile app needs the same renewal through an API endpoint, and someone copies the method.
• Operations wants a nightly command that auto-renews certain leases, and someone copies it again.
• You want to test the renewal rules, but the only way in is a full HTTP request.

Three copies later, a bug fix lands in one of them and not the others. That's the real cost of a fat controller: not ugliness, but logic you can't reuse.

The fix: give each job a proper home

Validation and authorization go to a Form Request

class RenewLeaseRequest extends FormRequest
{
    public function authorize(): bool
    {
        return $this->user()->can('renew', $this->route('lease'));
    }

    public function rules(): array
    {
        return ['months' => ['required', 'integer', 'in:6,12,24']];
    }
}

Laravel runs both before your controller method is even called. The actual rule ("who may renew this lease?") still lives in a policy, and the form request simply asks it.

The business operation goes to an action

An action is a plain class that does one thing. No base class, no package required:

class RenewLease
{
    public function handle(Lease $lease, int $months): Renewal
    {
        $renewal = DB::transaction(function () use ($lease, $months) {
            $lease->update(['status' => 'renewed']);

            return $lease->renewals()->create([
                'starts_at' => $lease->ends_at->copy()->addDay(),
                'ends_at' => $lease->ends_at->copy()->addMonths($months),
                'rent' => $lease->rent,
            ]);
        });

        Mail::to($lease->tenant)->queue(new LeaseRenewed($renewal));

        return $renewal;
    }
}

Notice what it doesn't know about: requests, redirects or HTTP. It takes plain values and returns a model. That's what makes it callable from a controller, an API endpoint, an Artisan command or a queued job, and testable without any of them.

Two small details I'd keep: the mail is queued after the transaction commits, so a rollback can't leave the tenant with an email about a renewal that doesn't exist. And copy() matters, because Laravel's date casts are mutable Carbon instances by default; calling addDay() directly would quietly change $lease->ends_at itself.

What's left in the controller is HTTP

class RenewLeaseController extends Controller
{
    public function __invoke(
        RenewLeaseRequest $request,
        Lease $lease,
        RenewLease $renew,
    ): RedirectResponse {
        $renew->handle($lease, $request->integer('months'));

        return to_route('leases.show', $lease);
    }
}

A single-action controller (php artisan make:controller RenewLeaseController --invokable) fits this nicely: one route, one class, one reason to change. You don't have to use them everywhere. A normal resource controller whose methods each call an action works just as well.

Actions, services or the model?

This is where teams argue, so here's the rule I use:

The trap on the other side is the fat model. Moving everything out of the controller and into Lease.php just gives you a 2,000-line model instead. Models are great for facts about a record. They're a poor home for workflows that touch five other tables and send emails.

And the trap with services is the LeaseService that slowly collects every lease-related method in the app. If your service has twenty unrelated public methods, it's a fat controller wearing a different hat. Splitting it into actions usually makes each one easier to find and to test.

Don't overdo it

Not every endpoint needs three classes. A controller method that loads a list with a scope and returns a view is fine as it is. I reach for actions when an operation has real rules, touches several tables, or will obviously be needed from somewhere else. Structure should follow complexity, not run ahead of it.

The checklist

• Controllers handle HTTP: take the request, call something, return a response.
• Validation and authorization live in Form Requests and Policies.
• Business operations live in small, verb-named action classes.
• Services wrap external systems; models hold facts about a record.
• Start simple, extract when the second caller shows up.

The Form Request docs are a good place to start if you haven't used them much.

Where does business logic live in your Laravel apps: actions, services, models, or something else entirely?