Jak strukturujete službu/architekturu pro velkou Laravel aplikaci?

Question

Accepted Answer

Jak Laravel aplikace roste, přístup "tlustý kontrolér / tlustý model" se stává obtížně udržovatelný. Větší aplikace těží z **dodatečných architektonických vrstev** — tříd služeb, action tříd, repozitářů, form requestů a jasné organizace domény — aby se obchodní logika zůstala organizovaná, testovatelná a udržovatelná.

## Problém: logika skončí na špatných místech

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

## Třídy služeb — zapouzdření obchodní logiky

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

**Třídy služeb** obsahují obchodní logiku, které mají kontroléry štíhlé (pouze zpracování HTTP) a modely zaměřené na data — a činí logiku opakovaně použitelnou a nezávisle testovatelnou.

## Další užitečné vzory pro velké aplikace

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

## Vedoucí principy

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

## Proč na tom záleží

Rozbumění struktury velké Laravel aplikace je důležité vědomosti na seniorní úrovni, protože konvence, které fungují pro malé aplikace (logika v kontrolérech a modelech), selhávají při větší škále — vedoucí k nafouknutým kontrolérům, "bohem" modelům, duplikované logice a kódu, který je obtížné testovat a udržovat.

Znalost dodatečných architektonických vrstev — zvláště **tříd služeb** (zapouzdření obchodní logiky, aby kontroléry zůstaly štíhlé a modely se soustředily na data, zatímco činí logiku opakovaně použitelnou a testovatelnou), plus action třídy, Form Requests (extrakce validace/autorizace), API Resources (řízení výstupu), vzor repozitáře (abstrakce přístupu k datům, je-li to nutné), events (oddělení vedlejších efektů), a **doménově orientovaná organizace** (seskupení podle funkce, jak aplikace roste) — je to, co vám umožňuje vytvářet udržovatelné, škálovatelné aplikace.

Vedoucí principy jsou důležité: **štíhlé kontroléry → služby → modely** vrstvení, jednotná odpovědnost a závislost na abstrakcích (rozhraní) pro testovatelnost a volné párování.

Rovněž důležitá je úsudek **nenadstrojovat** — přidávat vrstvy, když složitost skutečně to ospravedlňuje spíše než předčasně (výchozí nastavení Laravel je v pořádku pro jednodušší aplikace a reflexivní přidávání repozitářů/abstrakcí přidá nepotřebnou složitost).

Porozumění těmto architektonickým vzorům a principům (a zdrženlivosti) pro jejich aplikaci je cennné pro vytváření velkých, dlouhodobě fungujících Laravel aplikací, které zůstávají udržovatelnými, testovatelinými a srozumitelné, jak rostou — rozlišujícími vývojáře, kteří mohou architektovat škálovatelné aplikace od těch, jejichž rostoucí aplikace se zhroutí do zmatené, obtížně udržovatelného kódu.

Tato architektonická úsudek je znak seniorního vývoje Laravel a často relevantní problém pro vážné, rostoucí aplikace.