Multi-tenancy

Arrel no tiene ninguna estrategia de multi-tenancy propia, ni por dominio, ni por subdominio, ni por base de datos, porque ya hay buenas en el ecosistema Laravel (stancl/tenancy es la habitual) y no tiene sentido reinventar una peor. En su lugar, expone dos puntos de enganche para que conectes la tuya:

1. TenantResolver

namespace Arrel\Tenancy;

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

Impleméntalo y enlázalo en el contenedor:

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

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

Una vez enlazado, $this->tenant() está disponible dentro de cualquier Resource:

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

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

Sin ningún TenantResolver enlazado, $this->tenant() devuelve null, Arrel funciona igual de bien en una aplicación sin tenancy, sin tener que configurar nada.

2. Middleware

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

Este middleware se ejecuta antes de la autenticación y del propio routing de Arrel, en todas las rutas web y API del panel. Es donde identificas el tenant a partir de la petición (dominio, subdominio, cabecera...) y activas la conexión de base de datos correspondiente, para que cuando Arrel llegue a consultar cualquier Resource ya esté resolviendo contra la base de datos correcta.

Ninguno de estos dos puntos fuerza nada sobre cómo defines «tenant»: es una interfaz y un slot de middleware, no un sistema.