Aller au contenu

ADR-001 · Domain-Driven Design pour le backend

Attribut Valeur
Statut ✅ Accepté
Date Janvier 2024
Décideurs Équipe technique Primatch
Tags architecture, backend, organisation

Contexte

Le domaine métier de Primatch est riche et complexe : gestion de matchs avec des règles précises (format padel, validation de score), tournois avec des formats variables, système de classement ELO. La logique métier risquait d'être dispersée dans les controllers et les models Eloquent, rendant le code difficile à tester et à faire évoluer.

Les options envisagées étaient : 1. Architecture CRUD classique : Controllers → Models → DB (simple, mais logique métier dans les controllers) 2. Service Layer : Controllers → Services → Models (séparation légère) 3. Domain-Driven Design (DDD) : Domain / Application / Infrastructure / Http layers

Décision

Nous adoptons une architecture Domain-Driven Design avec la structure suivante :

app/
  Domain/{Feature}/       # Logique métier pure
    DTOs/                 # Objets de transfert de données
    Events/               # Événements domaine
    Models/               # Entités et Value Objects
    Repositories/         # Interfaces (contrats)
    Services/             # Services métier
  Infrastructure/
    Repositories/         # Implémentations Eloquent
  Http/
    Controllers/          # Point d'entrée HTTP
    Requests/             # Validation des inputs
    Resources/            # Transformation des outputs

Conséquences

✅ Avantages

  • Isolation du métier : la logique business ne dépend pas d'Eloquent ni de Laravel
  • Testabilité : les Services du Domain sont testables unitairement sans DB
  • Extensibilité : ajouter un domaine = créer un nouveau dossier Domain/{Feature}/
  • Vocabulaire partagé : les classes reflètent le glossaire métier

⚠️ Inconvénients

  • Courbe d'apprentissage : DDD est plus complexe qu'un CRUD simple
  • Verbosité : plus de fichiers pour des fonctionnalités simples
  • Over-engineering possible : pour les premières fonctionnalités simples

🔗 Impact

  • Architecture tests Pest Arch (tests/Architecture/) pour enforcer les boundaries
  • Tous les nouveaux domaines doivent suivre cette structure
  • Voir le guide pratique pour créer un nouveau domaine