How do you structure a service/architecture for a large Laravel app?

Question

Accepted Answer

As a Laravel application grows, the default "fat controller / fat model" approach becomes hard to maintain. Larger apps benefit from **additional architectural layers** — service classes, action classes, repositories, form requests, and clear domain organization — to keep business logic organized, testable, and maintainable.

## The problem: logic ends up in the wrong places

```text
Small apps: logic in controllers and models is fine.
Large apps: controllers get bloated, models become "god objects", logic is duplicated
→ hard to test, maintain, and reason about. Extract logic into dedicated layers.
```

## Service classes — encapsulate business logic

```php
<?php
// move complex business logic out of controllers into a service
class OrderService {
    public function __construct(
        private PaymentGateway $payments,
        private InventoryService $inventory,
    ) {}

public function placeOrder(User $user, array $items): Order {
        // orchestrate the business process — reusable, testable, focused
        DB::transaction(function () use ($user, $items) { /* ... */ });
    }
}

// the controller stays THIN — just delegates
public function store(StoreOrderRequest $request, OrderService $orders) {
    return $orders->placeOrder($request->user(), $request->validated());
}
```

**Service classes** hold business logic, keeping controllers thin (just handling HTTP) and models focused on data — and making the logic reusable and independently testable.

## Other useful patterns for large apps

```text
✓ Action classes — a single class per use-case (e.g. CreateUserAction) — very focused
✓ Form Requests — extract validation + authorization out of controllers
✓ API Resources — control response shape, separate from models
✓ Repository pattern — abstract data access behind interfaces (when you need it;
  often Eloquent suffices, so don't add it reflexively)
✓ Events/listeners — decouple side effects from core logic
✓ Domain-oriented organization — group code by feature/domain, not just by type
  (e.g. a modules/ structure) as the app grows
✓ Dependency injection + interfaces — for loose coupling and testability
```

## The guiding principles

```text
✓ Thin controllers (HTTP only) → services/actions (business logic) → models (data)
✓ Single Responsibility — each class does one thing
✓ Depend on abstractions (interfaces) for testability and flexibility
✗ Don't over-engineer — add layers when complexity justifies them, not prematurely
```

## Why it matters

Understanding how to structure a large Laravel application is important senior-level knowledge, because the conventions that work for small apps (logic in controllers and models) break down at scale — leading to bloated controllers, "god" models, duplicated logic, and code that's hard to test and maintain.

Knowing the additional architectural layers — especially **service classes** (encapsulating business logic to keep controllers thin and models focused, while making logic reusable and testable), plus action classes, Form Requests (extracting validation/authorization), API Resources (controlling output), the repository pattern (abstracting data access when needed), events (decoupling side effects), and **domain-oriented organization** (grouping by feature as the app grows) — is what lets you build maintainable, scalable applications.

The guiding principles matter: **thin controllers → services → models** layering, single responsibility, and depending on abstractions (interfaces) for testability and loose coupling.

Equally important is the judgment to **not over-engineer** — adding layers when complexity genuinely justifies them rather than prematurely (Laravel's defaults are fine for simpler apps, and reflexively adding repositories/abstractions adds needless complexity).

Understanding these architectural patterns and the principles (and restraint) for applying them is valuable for building large, long-lived Laravel applications that stay maintainable, testable, and comprehensible as they grow — distinguishing developers who can architect scalable applications from those whose growing apps collapse into tangled, hard-to-maintain code.

This architectural judgment is a hallmark of senior Laravel development and a frequently-relevant concern for serious, growing applications.