Aller au contenu principal

Actions

Statut​

Document de cadrage backend — version initiale.

État actuel​

Aucun dossier Actions généralisé n'est visible dans api/app/Modules.

La logique métier est principalement portée par les Services, les Requests, les Policies, les Jobs et certains objets de contexte.

Vision cible​

Les Actions peuvent être introduites pour représenter des cas d'usage précis, surtout lorsqu'une opération devient trop spécifique pour rester dans un service général.

Une Action doit représenter une intention métier claire :

  • ApproveClaim
  • PublishMairieAlerte
  • GeneratePlayLoopCampaign
  • ProcessStripeWebhook
  • ModeratePublication

Ces noms sont des exemples de convention, pas des classes confirmées.

Quand créer une Action​

Créer une Action si :

  • l'opération a un début et une fin clairs ;
  • elle orchestre plusieurs services ;
  • elle est déclenchée par HTTP, job ou commande ;
  • elle doit être testée isolément ;
  • elle ne correspond pas à une simple méthode CRUD.

Ne pas créer d'Action si :

  • le service existant reste lisible ;
  • la logique est courte ;
  • l'Action ne fait qu'appeler une seule méthode ;
  • cela ajoute une couche sans valeur.

Convention cible​

app/Modules/<Module>/Actions/
└── VerbNounAction.php

Exemple de forme :

final class ModeratePublicationAction
{
    public function handle(string $publicationId, array $data): void
    {
        // orchestration du cas d'usage
    }
}

Relation Services / Actions​

  • Le Service porte des capacités métier réutilisables.
  • L'Action orchestre un cas d'usage.
  • Le contrôleur peut appeler une Action pour une opération complexe.
  • Le job peut appeler la même Action si le cas d'usage est asynchrone.

Points à clarifier​

  • Décider si les Actions deviennent une convention officielle.
  • Définir leur namespace et suffixe.
  • Éviter la coexistence confuse Services/Actions.
  • Ajouter des tests ciblés si une Action est introduite.