Hogyan strukturálod egy nagy Laravel alkalmazás service/architecture rétegeit?

Question

Accepted Answer

Ahogy a Laravel alkalmazás növekszik, az alapértelmezett "vastag controller / vastag model" megközelítés nehézkessé válik karbantartani. A nagyobb alkalmazások profitálnak **további architekturális rétegekből** — service osztályok, action osztályok, repositoryk, form requestek, és egyértelmű domain szervezésből — hogy a business logic szervezett, tesztelhető és karbantartható maradjon.

## A probléma: a logika nem megfelelő helyekre kerül

```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 osztályok — üzleti logika elkülönítése

```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 osztályok** tartalmazzák az üzleti logikát, így a controllerek vékonyak maradnak (csak a HTTP kezelésért felelnek) és a modellek az adatokra fókuszálnak — és az logika újrafelhasználható és függetlenül tesztelhető.

## Egyéb hasznos minták nagy alkalmazásokhoz

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

## Az irányító elvek

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

## Miért van ennek jelentősége

Annak megértése, hogyan lehet egy nagy Laravel alkalmazást strukturálni, fontos senior szintű tudás, mivel az egyszerű alkalmazásokhoz funcionáló konvenciók (logika controllerekbe és modellekbe) méretezéskor megbomlanak — ami duzzadt controllerekhez, "isteni" modellekhez, megduplázott logikához, és nehéz tesztelhető és karbantartható kódhoz vezet.

Annak ismerete, hogy melyek az további architekturális rétegek — különösen **service osztályok** (üzleti logika elkülönítése, hogy a controllerek vékonyak és a modellek fókuszáltak maradjanak, ugyanakkor a logika újrafelhasználható és tesztelhető), valamint action osztályok, Form Requestek (validáció/autorizáció kiszervezése), API Resources (kimenet kontrollálása), a repository pattern (adatelérés absztrakciója, ha szükséges), events (mellékhatások leválasztása), és **domain-orientált szervezés** (csoportosítás funkció szerint, ahogy az alkalmazás növekszik) — ez az, ami lehetővé teszi a karbantartható, skálázható alkalmazások fejlesztését.

Az irányító elvek fontosak: **vékony controllerek → service-ek → modellek** rétegzés, egyetlen felelősség, és absztrakciókra (interfészekre) való függőség a tesztelhetőség és laza csatoláshoz.

Egyformán fontos a **túl-bonyolítás elkerülésének** ítélőképessége — rétegek hozzáadása, amikor az összetettség valóban indokolja, nem pedig korán (Laravel alapértelmezettei jók az egyszerűbb alkalmazásokhoz, és reflexív módon repositorykat/absztrakciókat hozzáadni szükségtelen összetettséget jelent).

Annak megértése, hogy ezek az architekturális minták és az elvek (és önmérsékleti) hogyan alkalmazhatók, értékes a nagy, hosszú élettartamú Laravel alkalmazások fejlesztéséhez, amelyek karbantarthatók, tesztelhetők és értelmezhetők maradnak, amint növekednek — megkülönböztetésül a skálázható alkalmazásokat felépíteni képes fejlesztőktől azokétól, akiknek növekvő alkalmazásai zavartan, nehéz karbantartható kóddá összeomlanak.

Ez az architekturális ítélőképesség a senior Laravel fejlesztés jellegzetes vonása, és gyakran releváns szempont a komoly, növekvő alkalmazások számára.