Le template d'administration est CoreUI dans sa version gratuite, c'est à dire pratiquement sans plugins. Personnellement je préfère AdminLTE.

DDD ?

Pour la réalisation de projets volumineux la question de l'organisation du code est cruciale. Le DDD (Domain-Driven Design) est est une collection de principes. En gros on divise le code en modèles de domaine, c'est une histoire de conception. Avec Laravel essentiellement on applique la POO qui est déjà une façon d'organiser le code. Alors quid du DDD ? Dans le cadre de boilerplate ce n'est en fait qu'une façon de diviser le code en modules fonctionnels. On a une première division :

Est-ce que cette approche est plus intéressante du découpage classique de Laravel ? En tout cas c'est l'organisation proposée par Boilerplate. Rien ne nous empêche de remettre tout dans l'ordre habituel mais pourquoi ne pas tenter l'expérience ?

Les contrôleurs

On ne trouve pas grand chose dans ces contrôleurs, essentiellement une méthode pour ouvrir une vue. Mais évidemment la plupart des contrôleurs se trouvent dans leurs domaines :

Les middlewares

On remarque l'ajout de LocaleMiddleware pour la gestion des locales. Mais ce ne n'est pas le seul middleware ajouté et on trouve les autres dans les domaines :

Les modèles

On trouve de nombreux traits. Ils servent pour gérer les attributs, les relations, les scopes et les méthodes spécifiques. Ça fait au final pas mal de fichiers. Par exemple pour le modèle User on trouve une rafale de traits :

class User extends Authenticatable implements MustVerifyEmail, TwoFactorAuthenticatable
{
    use HasRoles,
        Impersonate,
        MustVerifyEmailTrait,
        Notifiable,
        SoftDeletes,
        TwoFactorAuthentication,
        UserAttribute,
        UserMethod,
        UserRelationship,
        UserScope;

C'est un choix architectural...

Les routes

/*
 * Frontend Routes
 */
Route::group(['as' => 'frontend.'], function () {
    includeRouteFiles(__DIR__.'/frontend/');
});

L'espace de nom est analogue au chemin des dossiers. Ici on va dans le dossier frontend. Dans ce dossier dans le fichier auth.php on trouve par exemple :

Route::group(['as' => 'auth.'], function () {

Les providers

• ComposerServiceProvider pour ajouter des composeurs de vues,
• EventServiceProvider pour l'écoute des événements,
• HelperServiceProvider pour les helpers,
• LocaleServiceProvider pour les locales,
• ObserverServiceProvider pour l'observation des modèles.

Livewire et AlpineJS

Les tableaux de l'administration sont générés avec le package laravel-livewire-tables. J'avoue que je ne le connaissais pas et il a l'air sympathique. Il est basé sur Livewire qui fonctionne avec AlpineJS qui se présente lui-même comme le Tailwind de JavaScript. Si on veut utiliser Boilerplate on a donc intérêt à se familiariser avec tout ça !

<div x-data="{userType : '{{ $model::TYPE_USER }}'}">

<select name="type" class="form-control" required x-on:change="userType = $event.target.value">

On a là une autre directive, cette fois x-on avec l'écoute de l'événement change. Du coup quand on change le type d'utilisateur on affiche ou on masque d'autres champs de saisie :

Ca vous donne une idée du principe de fonctionnement d'AlpineJS qui est essentiellement déclaratif. C'est un peu entre JQuery et Vue.js. Pour une bonne présentation en français c'est ici.