Monolithe modulaire Symfony : frontières nettes sans microservices

Pourquoi rester monolithique ?

Moins de latence réseau, transactions plus simples, déploiement unique, observabilité centralisée. Le piège est le big ball of mud : tout le monde importe tout. La modularité structure le code comme si demain vous extrayiez un bounded context — sans l’obligation de le faire.

Organisation sous Symfony

• Namespaces par domaine : App\\Billing\\, App\\Inventory\\ — pas seulement Controller\\Entity\\Repository mélangés.
• Services publics du module : interfaces dans le module, implémentations injectées.
• Éviter que le module A charge les repositories du module B : passer par un port (interface application) ou des événements de domaine.

Frontière données

Partager une base SQL reste possible : tables par contexte ou schémas logiques, pas de clés étrangères « travers contextes » si cela crée du couplage fort. Sinon, synchronisation par événements ou API interne documentée.

Règles automatiques

Outils du type deptrac (couches et namespaces interdits) transforment les conventions en garde-fous CI. Une PR qui viole une règle est refusée — moins de dette silencieuse.

FAQ

Symfony « bundle » par domaine ?

Possible pour de gros projets ; souvent un namespace + services tagués suffisent. Les bundles brillent quand le domaine est réutilisable entre applications.

Quand basculer vers des services séparés ?

Quand les équipes, les cycles de release ou les contraintes de scale imposent l’isolation — pas comme premier reflexe d’« architecture propre ».