Imaginez en Laravel cette simple commande permettant de créer un nouveau model Post :
class AddPost extends Command
{
protected $signature = 'app:add-post {name}';
public function handle()
{
$name = $this->argument('name');
Post::create([
'name' => $name,
'live' => false,
]);
}
}
Ce code, bien que pleinement fonctionnel peut s'avérer contraignant sur certain aspect.
Il est important de se poser la question suivante : utiliser une commande doit-elle être la seule façon de créer un nouveau poste ?
Une commande, un contrôleur, voire même un job ne sont ne sont que des contextes d'utilisation parmi d'autres. Ils ne devraient contenir de la logique métier qu'avec discernement en ayant pleinement conscience du couplage que cela engendrera.
Autrement dit, une commande n'est qu'une façon parmi tant d'autre d'accéder à la logique métier.
Du point de vue fonctionnel, la création d'un poste n'est aucunement liée à l'utilisation d'une commande, la seule véritable responsabilité de cette dernière est de préparer une liste d'arguments, dans notre cas : le name.
Dans bien des situations vous gagnerez en souplesse d'utilisation en dissociant "contexte" et "logique métier" tout en facilitant les tests de ces différentes briques fonctionnelles.
Pour conserver un code réutilisable et modulable, prenez l'habitude de dissocier la logique de son contexte d'utilisation. :
class AddPost extends Command
{
protected $signature = 'app:add-post {name}';
public function handle()
{
$name = $this->argument('name');
app(PostService::class)->create($name);
}
}
En encapsulant la logique de création d'un post dans un nouveau service, votre application sera mieux découplée.
Les différentes responsabilités seront ainsi mieux segmentées et l'ajout de ce service rendra l'action de créer un post réutilisable dans d'autre contextes.