How do you structure large Laravel projects?

[Oliversenseii]

As projects grow bigger, I’m starting to wonder how experienced developers organize Laravel applications.

Do you:

• Separate services/actions/repositories?
• Use domain-driven structure?
• Keep controllers thin?
• Use API resources everywhere?

I’d appreciate examples or recommended project structures.

[phanduykhai05]

Great question — this is one of the most important (and debated) topics in Laravel. Let me show you a practical, battle-tested approach.
The core philosophy most experienced teams converge on: thin controllers, fat service/action layer, explicit data flow. Here's how the pieces fit together:

Controllers — keep them dumb
A controller's only job: receive the request, hand it off, return a response.
phpclass OrderController extends Controller
{
public function store(StoreOrderRequest $request, CreateOrder $action)
{
$order = $action->execute($request->validated());

    return new OrderResource($order);
}

}
No business logic. No Eloquent queries. No if/else chains. The StoreOrderRequest handles validation; the CreateOrder action handles the work.

Actions vs Services — pick one style
Actions are single-purpose invokables, popularized by the lorisleiva/laravel-actions package. One class = one thing:
phpclass CreateOrder
{
public function __construct(
private OrderRepository $orders,
private NotificationService $notifications,
) {}

public function execute(array $data): Order
{
    $order = $this->orders->create($data);
    $this->notifications->orderCreated($order);

    return $order;
}

}
Services group related operations together — useful when you have 5–6 related actions that share dependencies (PaymentService with charge(), refund(), getHistory()).
Many teams use both: services for infrastructure concerns (payments, notifications, storage) and actions for business workflows.

Repositories — optional, but worth it
Repositories abstract your query logic away from the rest of the app:
phpclass OrderRepository
{
public function create(array $data): Order
{
return Order::create($data);
}

public function getPendingForUser(User $user): Collection
{
    return Order::query()
        ->where('user_id', $user->id)
        ->where('status', 'pending')
        ->with(['items.product'])
        ->latest()
        ->get();
}

}
The benefit: your actions never contain raw Eloquent chains, so complex queries stay testable and reusable. For smaller apps, this layer is overkill — calling Eloquent directly from actions is fine.

API Resources — yes, use them everywhere
Resources decouple your database shape from your API shape, which prevents accidental data leaks and gives you a single place to evolve the response:
phpclass OrderResource extends JsonResource
{
public function toArray(Request $request): array
{
return [
'id' => $this->id,
'status' => $this->status,
'total' => $this->total_cents / 100,
'items' => OrderItemResource::collection($this->items),
'created_at' => $this->created_at->toISOString(),
];
}
}
Use ResourceCollection for paginated lists. Never return $model->toJson() directly from a controller.

[sam-dev-161127]

As Laravel projects grow, many experienced developers keep controllers thin and move business logic into services, actions, or repositories to make the code easier to maintain and test. A common approach is to organize code by feature or domain instead of only by technical type, grouping related models, controllers, services, requests, and resources together. API Resources are often used to ensure consistent API responses, while Form Requests handle validation. There is no single perfect structure, but the main goal is to keep code clean, modular, and easy to understand as the application becomes larger and more complex.

[sam-dev-161127]

Please star mine repo here is it, https://github.com/Sam-Dev-161127/Nexaura. You can also start my other repo