Multi-tenancy

Arrel n'a aucune stratégie de multi-tenancy propre, ni par domaine, ni par sous-domaine, ni par base de données, car il en existe déjà de bonnes dans l'écosystème Laravel (stancl/tenancy est la plus courante) et il n'y a aucun intérêt à en réinventer une moins bonne. À la place, il expose deux points d'accroche pour y brancher la vôtre :

1. TenantResolver

namespace Arrel\Tenancy;

interface TenantResolver
{
    public function resolve(): mixed;
}

Implémentez-le et liez-le dans le conteneur :

final class StanclTenantResolver implements TenantResolver
{
    public function resolve(): mixed
    {
        return tenant();
    }
}

// AppServiceProvider::register()
$this->app->bind(TenantResolver::class, StanclTenantResolver::class);

Une fois lié, $this->tenant() est disponible dans n'importe quel Resource :

public function canViewAny(): bool
{
    return $this->tenant()->hasFeature('students');
}

public function getEloquentQuery(): Builder
{
    return parent::getEloquentQuery()->where('tenant_id', $this->tenant()->id);
}

Sans aucun TenantResolver lié, $this->tenant() retourne null, Arrel fonctionne aussi bien dans une application sans tenancy, sans rien à configurer.

2. Middleware

// config/arrel.php
'middleware' => [
    \App\Http\Middleware\IdentifyTenant::class,
],

Ce middleware s'exécute avant l'authentification et le routing propre d'Arrel, sur toutes les routes web et API du panneau. C'est là que vous identifiez le tenant à partir de la requête (domaine, sous-domaine, en-tête...) et activez la connexion de base de données correspondante, pour que lorsqu'Arrel interroge un Resource, il résolve déjà sur la bonne base de données.

Aucun de ces deux points n'impose quoi que ce soit sur la façon dont vous définissez « tenant » : c'est une interface et un emplacement de middleware, pas un système.