Kako strukturirati servis/arhitekturu za veliku Laravel aplikaciju?

Question

Accepted Answer

Kako Laravel aplikacija raste, zadani pristup "debeli kontroler / debeli model" postaje teško održavati. Veće aplikacije se koriste od **dodatnih arhitekturnih slojeva** — servisne klase, action klase, repositories, form requests, i jasne organizacije domene — kako bi se poslovnu logiku organizirala, testirala i održavala.

## Problem: logika završi na pogrešnim mjestima

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

## Servisne klase — enkapsulacija poslovne logike

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

**Servisne klase** čuvaju poslovnu logiku, čineći kontrolere tankim (samo rukovanje HTTP-om) i modele fokusirane na podatke — i čineći logiku ponovnom upotrebljivom i nezavisno testabilnom.

## Ostri korisni obrasci za velike aplikacije

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

## Vodeća načela

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

## Zašto je važno

Razumijevanje kako strukturirati veliku Laravel aplikaciju je važno znanje na razini seniora, jer konvencije koje funkcioniraju za male aplikacije (logika u kontrolerima i modelima) se raspadaju pri većoj skali — što dovodi do napuhanih kontrolera, "bog" modela, duplicirane logike, i koda koji je teško testirati i održavati.

Znanje dodatnih arhitekturnih slojeva — posebno **servisnih klasa** (enkapsulacija poslovne logike kako bi se kontroleri čuvali tankim i modeli fokusirani, dok se logika čini ponovnom upotrebljivom i testabilnom), plus action klase, Form Requests (ekstrakcija validacije/autorizacije), API Resources (kontrola izlaza), repository obraz (apstrakcija pristupa podacima kada je potrebno), events (odvajanje sporednih efekata), i **organizacija orijentirana na domenu** (grupianje po značajki dok aplikacija raste) — je ono što vam omogućava izgradnju održavih, skalabilnih aplikacija.

Vodeća načela su važna: **tanki kontroleri → servisi → modeli** slojevanje, pojedinačna odgovornost, i ovisnost o apstrakcijama (sučeljima) za testabilnost i labavo spajanje.

Jednako važna je prosudba da **se ne preljenči arhitektura** — dodavanje slojeva kada složenost stvarno to opravdava umjesto preuranoga dodavanja (Laravelove zadane postavke su fine za jednostavnije aplikacije, i mehanički dodavanje repositories/apstrakcija dodaje nepotrebnu složenost).

Razumijevanje ovih arhitekturnih obrazaca i načela (i suzdržavanja) za njihovu primjenu je vrijedna za izgradnju velikih, dugotrajnih Laravel aplikacija koje ostaju održavane, testabilne, i razumljive dok rastu — razlikujući razvojne inženjere koji mogu projektirati skalabilne aplikacije od onih čije rastuće aplikacije kolabiraju u zbrkanu, teško održavanu kodu.

Ova arhitekturna prosudba je označitelja seniorskog Laravel razvoja i često relevantna briga za ozbiljne, rastuće aplikacije.