CMS, CRM, LLM : une stack modulaire qui scale

Trois modules métiers cohabitent sur Jul6art : CMS pour le site public, CRM pour la relation prospect/client, LLM pour la génération assistée. Chacun a ses entités, ses voters, ses settings, ses traductions, ses tests. Comment éviter qu'ils ne deviennent un monolithe géant ?

Découpage strict par dossier

Chaque module vit sous src/Modules/<Module>/ avec son propre Entity/, Repository/, Service/, Controller/, Voter/, Form/, EntityListener/. Les dépendances entre modules sont explicites : le CMS ne connaît pas le CRM, mais les deux connaissent App\Modules\Organization et App\Modules\User.

Settings module-scopés

Chaque module déclare une classe ModuleSettingsDefaultsInterface qui liste ses settings par défaut. Le seeder provisionne automatiquement les rows à l'activation de la feature, et un reader typé (CmsSettingsReader, CrmSettingsReader) expose les valeurs aux services. Pas de magic strings dispersés.

Permissions par module

Un fichier DefaultRolePermissions::$permissionsByFeature liste les PermissionCodes::* distribués à chaque feature. Le mapping rôle ↔ permission par défaut peut être surchargé tenant par tenant, et override par utilisateur si besoin.

Tests qui ne se marchent pas dessus

Chaque module a son propre arbre de tests sous tests/Unit/Modules/<Module>/ et tests/Functional/<Module>/. Les fixtures sont mutualisées (OrganizationFixtures, UserFixtures) mais les tests fonctionnels créent leur propre tenant pour rester isolés.

Résultat : trois modules de quelques milliers de lignes chacun, qui évoluent en parallèle, sans collision, avec une couverture de tests dépassant les 947 cas verts.