Hvordan strukturerer du en service/arkitektur for en stor Laravel-app?

Question

Accepted Answer

Når en Laravel-applikation vokser, bliver standardtilgangen "fed controller / fed model" svær at vedligeholde. Større apps gavner fra **yderligere arkitektoniske lag** — service-klasser, action-klasser, repositories, form requests og klar domæneorganisering — for at holde forretningslogik organiseret, testbar og vedligeholdelig.

## Problemet: logik ender op på de forkerte steder

```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-klasser — indkapsling af forretningslogik

```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-klasser** indeholder forretningslogik, hvilket holder controllere tynde (håndterer kun HTTP) og modeller fokuseret på data — og gør logikken genanvendelig og uafhængigt testbar.

## Andre nyttige mønstre for store 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
```

## Vejledende principper

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

## Hvorfor det betyder noget

At forstå, hvordan man strukturerer en stor Laravel-applikation, er vigtig viden på seniorniveau, fordi de konventioner, der fungerer for små apps (logik i controllere og modeller), bryder sammen i større skala — hvilket fører til oppustede controllere, "gud"-modeller, duplikeret logik og kode, der er svær at teste og vedligeholde.

At kende de yderligere arkitektoniske lag — især **service-klasser** (indkapsling af forretningslogik for at holde controllere tynde og modeller fokuseret, samtidig med at logikken gøres genanvendelig og testbar), plus action-klasser, Form Requests (ekstrahering af validering/autorisation), API Resources (kontrol af output), repository-mønsteret (abstraktion af dataadgang når det er nødvendigt), events (afkoblet af bivirkninger) og **domæne-orienteret organisering** (gruppering efter funktion når appen vokser) — er hvad der gør det muligt for dig at bygge vedligeholdelige, skalerbare applikationer.

De vejledende principper betyder noget: **tynde controllere → services → modeller** lagdeling, single responsibility, og afhængighed af abstraktioner (interfaces) for testabilitet og løs kobling.

Ligeligt vigtig er dømmekraften til **ikke at over-engineer** — tilføje lag når kompleksiteten virkelig retfærdiggør dem snarere end forhåndsrettet (Laravels standarder er fint for enklere apps, og reflexivt tilføjelse af repositories/abstraktioner tilføjer unødvendig kompleksitet).

At forstå disse arkitektoniske mønstre og principperne (og tilbageholdenhed) for at anvende dem er værdifuldt for at bygge store, længevarende Laravel-applikationer, der forbliver vedligeholdelige, testbare og forståelige, når de vokser — og adskiller udviklere, der kan arkitekturere skalerbare applikationer, fra dem, hvis voksende apps kollapser til rodet, svært vedligeholdelig kode.

Denne arkitektoniske dømmekraft er et kendetegn på senior Laravel-udvikling og en hyppigt relevant bekymring for seriøse, voksende applikationer.