Comment structurer un service/une architecture pour une grande application Laravel ?

Question

Accepted Answer

À mesure qu'une application Laravel grandit, l'approche par défaut « contrôleur gras / modèle gras » devient difficile à maintenir. Les applications plus grandes bénéficient de **couches architecturales supplémentaires** — classes de service, classes d'action, dépôts, form requests, et organisation claire du domaine — pour garder la logique métier organisée, testable et maintenable.

## Le problème : la logique se retrouve au mauvais endroit

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

## Classes de service — encapsuler la logique métier

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

Les **classes de service** contiennent la logique métier, gardant les contrôleurs minces (gérant simplement HTTP) et les modèles axés sur les données — et rendant la logique réutilisable et testable indépendamment.

## Autres motifs utiles pour les grandes applications

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

## Les principes directeurs

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

## Pourquoi c'est important

Comprendre comment structurer une grande application Laravel est une connaissance importante au niveau senior, car les conventions qui fonctionnent pour les petites applications (logique dans les contrôleurs et les modèles) s'effondrent à grande échelle — menant à des contrôleurs gonflés, des modèles « dieu », une logique dupliquée, et du code difficile à tester et maintenir.

Connaître les couches architecturales supplémentaires — en particulier les **classes de service** (encapsulant la logique métier pour garder les contrôleurs minces et les modèles axés, tout en rendant la logique réutilisable et testable), plus les classes d'action, les Form Requests (extrayant la validation/autorisation), les API Resources (contrôlant la sortie), le motif de dépôt (abstrayant l'accès aux données si nécessaire), les événements (découplant les effets secondaires), et l'**organisation orientée domaine** (regroupant par fonctionnalité à mesure que l'application grandit) — c'est ce qui vous permet de construire des applications maintenables et évolutives.

Les principes directeurs sont importants : couches **contrôleurs minces → services → modèles**, responsabilité unique, et dépendre d'abstractions (interfaces) pour la testabilité et le couplage faible.

Également important est le jugement de **ne pas sur-ingéniérer** — ajouter des couches quand la complexité le justifie réellement plutôt que prématurément (les paramètres par défaut de Laravel conviennent aux applications plus simples, et ajouter réflexivement des dépôts/abstractions ajoute une complexité inutile).

Comprendre ces motifs architecturaux et les principes (et la retenue) pour les appliquer est précieux pour construire des grandes applications Laravel durables qui restent maintenables, testables et compréhensibles à mesure qu'elles grandissent — distinguant les développeurs qui peuvent architecturer des applications évolutives de ceux dont les applications qui grandissent s'effondrent en code enchevêtré et difficile à maintenir.

Ce jugement architectural est une marque du développement Laravel senior et une préoccupation fréquemment pertinente pour les applications sérieuses et en croissance.