Hoe structureer je een service/architectuur voor een grote Laravel-app?

Question

Accepted Answer

Naarmate een Laravel-applicatie groeit, wordt de standaard "fat controller / fat model"-benadering moeilijk te onderhouden. Grotere apps profiteren van **aanvullende architectuurlagen** — serviceklassen, actionklassen, repositories, form requests, en duidelijke domeinorganisatie — om bedrijfslogica georganiseerd, testbaar en onderhoudbaar te houden.

## Het probleem: logica eindigt op de verkeerde plekken

```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.
```

## Serviceklassen — encapsuleer bedrijfslogica

```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());
}
```

**Serviceklassen** bevatten bedrijfslogica, waardoor controllers slim blijven (alleen HTTP-verwerking) en modellen gericht op data — en de logica herbruikbaar en onafhankelijk testbaar wordt.

## Andere nuttige patronen voor grote 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
```

## De leidende principes

```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
```

## Waarom het belangrijk is

Het begrijpen hoe je een grote Laravel-applicatie structureert, is belangrijke kennis op senior level, omdat de conventies die werken voor kleine apps (logica in controllers en modellen) niet schalen — wat leidt tot opgezwollen controllers, "god" modellen, gedupliceerde logica, en code die moeilijk te testen en onderhouden is.

Het kennen van de aanvullende architectuurlagen — vooral **serviceklassen** (bedrijfslogica encapsuleren om controllers slim en modellen gericht te houden, terwijl logica herbruikbaar en testbaar blijft), plus actionklassen, Form Requests (validatie/autorisatie extractie), API Resources (output-controle), het repository-patroon (data access abstraheren wanneer nodig), events (side effects ontkoppelen), en **domein-georiënteerde organisatie** (groeperingen per feature naarmate de app groeit) — is wat je in staat stelt onderhoudbare, schaalbare applicaties te bouwen.

De leidende principes zijn belangrijk: **dunne controllers → services → modellen** lagen, single responsibility, en afhankelijkheid van abstracties (interfaces) voor testbaarheid en losse koppeling.

Evenso belangrijk is het inzicht om **niet te over-engineeren** — lagen toevoegen wanneer complexiteit dit echt rechtvaardigt in plaats van voortijdig (Laravel's standaardinstellingen zijn prima voor eenvoudigere apps, en reflexmatig repositories/abstracties toevoegen leidt tot onnodige complexiteit).

Het begrijpen van deze architectuurpatronen en de principes (en terughoudendheid) voor hun toepassing is waardevol voor het bouwen van grote, langdurige Laravel-applicaties die onderhoudbaar, testbaar en begrijpelijk blijven naarmate ze groeien — dit onderscheidt ontwikkelaars die schaalbare applicaties kunnen architecteren van degenen wiens groeiende apps in spaghettihoden vervallen die moeilijk te onderhouden zijn.

Deze architectuurbeoordelingscapaciteit is een kenmerk van senior Laravel-ontwikkeling en een veelvuldig relevant aandachtspunt voor serieuze, groeiende applicaties.