Imaginez 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 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.
Allez plus loin
Ces premières réflexions sont intéressantes afin d'améliorer le découplage de votre application et d'éviter de faire des erreurs grossières pouvant rapidement mettre à mal la flexibilité de votre application.
Des formes d'architectures plus spécifiques axées sur la flexibilité et l'ouverture aux changements existent, telles que la Clean Architecture ou l'hexagonale, et seront bien plus intéressantes et pertinentes si vous souhaitez faire grandir votre application dans le temps.