Principes
Core purity, minimal by default, sécuritaire par défaut, performant, et les règles absolues qui en découlent.
Cette page dit pourquoi le code est structuré comme il l'est. Elle suppose le vocabulaire de la plateforme acquis : Les concepts le pose en une page.
Les quatre principes
Core purity. Chaque core contient uniquement du code propre à son domaine. Aucune logique métier, aucune dépendance vers un autre core. C'est ce qui permet de remplacer un provider de stockage ou de courriel sans toucher au reste.
Minimal by default. Pas de fonctionnalité superflue. Si ce n'est pas nécessaire, ça n'existe pas. Une abstraction ajoutée « au cas où » coûte plus cher à retirer qu'à écrire.
Sécuritaire par défaut. Requêtes paramétrées, protection CSRF, limitation de débit, validation en entrée, erreurs opaques vers le client. Le comportement sûr est celui qu'on obtient sans rien configurer. Voir Sécurité.
Performant. Connexions en pool, cache HTTP, génération différée des services.
Structure
src/
core/ infrastructure fondamentale — la base de tout
features/ fonctionnalités de la plateforme utilisant les cores
shared/ utilitaires, composants et styles partagésÀ quoi s'ajoutent deux registres de contenu à la racine de src/, blocks-registry/ et media-registry/, qui portent un format de données partagé plutôt qu'un service.
Règles absolues
Elles ne souffrent pas d'exception. Chacune existe pour qu'un comportement transverse (sécurité, pooling, journalisation, invalidation) reste modifiable en un seul endroit.
| Domaine | Règle |
|---|---|
| API | Toutes les routes HTTP passent par core/api. Aucune autre route API. |
| Base de données | Tout accès DB passe par core/database. Jamais de requête directe. |
| Courriels | Tout envoi passe par core/email. |
| Cron | Toutes les tâches planifiées s'enregistrent dans core/cron. |
| Stockage | Tout accès fichier passe par core/storage. |
| Notifications | Un seul système de toast : core/toast. |
| Authentification | Toute auth de site passe par features/auth. |
Extensibilité
Le core n'est jamais modifié pour ajouter une fonctionnalité applicative. Trois voies existent, par ordre d'engagement croissant :
- Extensions in-projet : un fichier
lrvo.extensions.jsqui appelle les fonctions d'enregistrement de l'admin. Voir Étendre l'admin. - Module
@lrvo/module-*: un package npm auto-découvert, réutilisable entre projets. Voir Créer un module. - Modification du core : seulement quand le besoin est structurel et concerne tous les projets.
Si une fonctionnalité peut vivre en module, elle vit en module.