Laravel : Arrêtez de tuer votre Monolithe
Mis à jour le 7 janvier 2026

Laravel : Arrêtez de tuer votre Monolithe

Vous pensez que votre application Laravel est trop grosse et qu'il faut tout casser en microservices ? Faux. Le problème n'est pas la taille, c'est le rangement. Je vous montre comment transformer un plat de spaghettis en architecture solide avec les outils de Spatie.

Le dossier app/ par défaut de Laravel est un mensonge. Il est parfait pour un MVP, un blog ou un petit SaaS. Mais pour une application métier qui vit depuis 3 ans avec 15 développeurs ? C'est un piège mortel.

J'ai vu des équipes brûler des millions pour migrer vers des microservices simplement parce qu'elles ne savaient plus où ranger leurs fichiers. Spoiler : elles ont échoué. Elles ont juste créé un plat de spaghettis distribué (et beaucoup plus cher).

Avant de sortir Kubernetes, apprenez à ranger votre chambre. Voici comment je structure mes monolithes pour qu'ils durent 10 ans, en utilisant intelligemment l'écosystème Spatie.

1. Sortez du dogme MVC par défaut

Le problème n'est pas Laravel. Le problème, c'est de tout mettre dans app/Http/Controllers et app/Models.

Quand votre application grossit, le découpage technique (Controllers, Models, Jobs) devient illisible. Vous devez passer à un découpage Fonctionnel (ou par Domaine).

Dans mes projets, je sépare le code en trois couches strictes :

  1. App : La couche HTTP (Controllers, Requests, Middleware). C'est l'entrée.
  2. Domain : La logique métier pure (Models, Actions, DTOs). C'est le cœur.
  3. Support : Les outils transverses (Traits, Helpers).
Attention au couplage : Votre couche Domain ne doit JAMAIS dépendre de la couche App. Le métier ne doit pas savoir qu'il est appelé par une requête HTTP, une commande Artisan ou un Job.
Du Chaos au Domaine : Structurer les flux
Du Chaos au Domaine : Structurer les flux

2. Tuez les tableaux associatifs avec laravel-data

Si vous passez des tableaux $data de votre Controller à vos Services, vous faites du PHP des années 2000. C'est la source n°1 de bugs en prod : "Undefined index: user_id".

Le package spatie/laravel-data est, à mon avis, le plus important de l'écosystème actuel. Il transforme vos tableaux flous en objets typés et immuables.

Avant (Le chaos)

// UserController.php
public function update(Request $request, User $user)
{
    // Validation implicite, on ne sait pas ce qui sort
    $validated = $request->validate([...]);
    
    // On passe un array magique
    $this->userService->update($user, $validated);
}

Après (La sérénité)

On définit un DTO (Data Transfer Object) qui sert aussi de Request Validator.

// UserData.php
class UserData extends Data
{
    public function __construct(
        public string $name,
        public string $email,
        #[Rule(['nullable', 'string', 'min:8'])]
        public ?string $password
    ) {}
}

// UserController.php
public function update(UserData $userData, User $user, UpdateUserAction $action)
{
    // $userData est déjà validé et typé ici.
    // L'injection de dépendance le fait automatiquement.
    $action->execute($user, $userData);
}
L'astuce Pro : Utilisez laravel-data pour vos réponses API. Au lieu de retourner des Resources Eloquent souvent trop liées à la DB, retournez un objet Data. Vous maîtrisez exactement ce qui sort.

3. Nettoyez vos Vues avec laravel-view-models

Un autre signe de pourrissement : les contrôleurs qui préparent 15 variables pour la vue.

return view('dashboard', [
    'user' => $user,
    'stats' => $stats,
    'latestPosts' => $posts,
    'notifications' => $notifications,
    // Et ça continue...
]);

C'est illisible et intestable. Le package spatie/laravel-view-models vous force à encapsuler cette logique.

Le contrôleur ne fait plus qu'une chose : instancier le ViewModel.

class DashboardController
{
    public function __invoke()
    {
        return new DashboardViewModel(Auth::user());
    }
}

Le ViewModel gère la récupération des données. Votre contrôleur redevient ce qu'il aurait toujours dû être : un simple agent de circulation.

Le mot de la fin

La complexité ne disparaît pas, elle se déplace. Si vous ne la structurez pas activement, elle s'infiltre partout comme de la moisissure.

N'écoutez pas les sirènes des microservices avant d'avoir atteint les limites physiques de votre monolithe. Avec une structure par Domaine et des données typées grâce aux outils de Spatie, vous pouvez scaler jusqu'à des centaines de milliers de lignes de code sans perdre la tête.

Restez pragmatiques. Codez solide.

Un projet en tête ?

Discutons de vos besoins techniques et voyons comment je peux vous aider à concrétiser votre projet.

Me contacter