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

Question

Accepted Answer

Når en Laravel-applikasjon vokser, blir standard "fat controller / fat model"-tilnærmingen vanskelig å vedlikeholde. Større apper drar nytte av **ekstra arkitekturlags** — service-klasser, action-klasser, repositories, form requests, og klar domenorganisering — for å holde forretningslogikk organisert, testbar og vedlikeholdbar.

## Problemet: logikk ender opp på feil 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 — innkapsle forretningslogikk

```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** holder forretningslogikk, holder controllere tynne (bare håndterer HTTP) og modeller fokusert på data — og gjør logikken gjenbrukbar og uavhengig testbar.

## Andre nyttige mønstre for store apper

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

## Veiledende prinsipper

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

Å forstå hvordan man strukturerer en stor Laravel-applikasjon er viktig senior-nivå-kunnskap, fordi konvensjonene som fungerer for små apper (logikk i controllere og modeller) bryter sammen i stor skala — noe som fører til oppblåste controllere, "gud"-modeller, duplisert logikk, og kode som er vanskelig å teste og vedlikeholde.

Å kjenne til de ekstra arkitekturlags — spesielt **service-klasser** (innkapsling av forretningslogikk for å holde controllere tynne og modeller fokusert, samtidig som logikken blir gjenbrukbar og testbar), pluss action-klasser, Form Requests (ekstrahering av validering/autorisering), API Resources (kontroll av utdata), repository-mønsteret (abstraksjon av datakafgang når nødvendig), events (frakopling av bivirkninger), og **domenorientert organisering** (gruppering etter funksjon når appen vokser) — er det som lar deg bygge vedlikeholdbare, skalerbare applikasjoner.

Veiledende prinsipper er viktige: **tynne controllere → services → modeller** lagdeling, ansvarsprinsippet, og avhengighet av abstraksjoner (interfaces) for testbarhet og løs kobling.

Likeviktig er dømmekraft for å **ikke over-engineering** — legge til lag når kompleksitet genuint rettferdiggjør dem i stedet for prematurt (Laravels standarder er fine for enklere apper, og refleksivt å legge til repositories/abstraksjoner legger til unødvendig kompleksitet).

Å forstå disse arkitekturmønstrene og prinsippene (og tilbakeholdenhet) for å bruke dem er verdifullt for å bygge store, langvarige Laravel-applikasjoner som forblir vedlikeholdbare, testbare og forståelige når de vokser — og skiller utviklere som kan arkitekturere skalerbare applikasjoner fra dem hvis voksende apper kollapser i rotete, vanskelig-å-vedlikeholde kode.

Denne arkitekturelle dømmekraften er et kjennetegn ved senior Laravel-utvikling og en hyppig relevant bekymring for seriøse, voksende applikasjoner.