netslim-core/docs/PUBLIC_API.md

API publique et API interne de netslim-core

Ce document définit la frontière de support du package netslim-core.

API publique

Les applications consommatrices peuvent dépendre des éléments suivants :

• le namespace Netig\Netslim\Kernel\Runtime\... nécessaire au bootstrap, au runtime et à la découverte des modules ;
• les classes *Module exposées par les modules partagés (IdentityModule, SettingsModule, AuditLogModule, NotificationsModule, TaxonomyModule, MediaModule, KernelModule) ;
• les interfaces applicatives explicitement exposées par les modules (Identity\Application\*ServiceInterface, Settings\Application\SettingsServiceInterface, AuditLog\Application\AuditLogServiceInterface, Notifications\Application\NotificationServiceInterface, Taxonomy\Application\TaxonomyServiceInterface, Media\Application\MediaServiceInterface) ;
• les contrats publics sous Netig\Netslim\*/Contracts/ ;
• les conventions documentées de config/modules.php, public/index.php et des chemins runtime résolus côté projet consommateur ;
• les layouts et partials Twig documentés sous @Kernel/... quand l'application choisit de les réutiliser.

API interne

Les éléments suivants doivent être considérés comme des détails d'implémentation du package :

• tout Infrastructure/ (repositories PDO, stockage local, wiring DI, maintenance post-migration) ;
• tout Application/UseCase/ et les services applicatifs non documentés comme contrats ;
• les entités de domaine utilisées en interne par les modules ;
• les vérifications de démarrage propres aux modules ;
• les templates Twig non documentés comme points d'intégration.

Une application consommatrice ne devrait pas dépendre directement de ces éléments internes.

Règle pratique

Quand un projet applicatif a besoin d'une capacité partagée, il doit préférer :

1. un contrat public existant dans Contracts/ ;
2. à défaut, une extension documentée du runtime ou d'un module ;
3. en dernier recours, une évolution du core qui ajoute un nouveau point d'intégration public.

Éviter de se brancher directement sur des classes internes permet de garder le core petit, lisible et évolutif.