Architecture hexagonale PHP / DDD Symfony
Architecture hexagonale avec Symfony : Domain-Driven Design appliqué
Votre application Symfony mélange règles métier, controllers et requêtes Doctrine dans les mêmes classes ? Chaque évolution devient risquée et chaque test un calvaire ?
L'architecture hexagonale isole votre domaine métier de Symfony. Le framework devient un détail d'implémentation, pas une contrainte structurante. Votre code métier reste pur, testable et indépendant.
Un premier échange de 30 minutes, gratuit et sans engagement.
Les principes de l'architecture hexagonale
L'architecture hexagonale, aussi appelée architecture ports et adaptateurs, repose sur un principe simple : le domaine métier ne dépend de rien. Tout le reste gravite autour de lui.
Le domaine au centre
Le code métier est isolé dans un noyau indépendant de tout framework. Les règles de gestion ne dépendent ni de Symfony, ni de Doctrine, ni d'aucune librairie externe.
Ports et adaptateurs
Les interactions avec l'extérieur passent par des interfaces (ports) implémentées par des adaptateurs concrets. Changer de base de données ou de système de file d'attente ne touche pas au domaine.
Inversion de dépendance
Les couches externes dépendent du domaine, jamais l'inverse. Le domaine définit les contrats, l'infrastructure les implémente.
Testabilité native
Un domaine sans dépendance externe se teste unitairement sans mock complexe. Les tests deviennent rapides, fiables et faciles à maintenir.
Ubiquitous Language
Le code utilise le vocabulaire métier. Développeurs et experts fonctionnels parlent le même langage, ce qui réduit les malentendus et accélère les échanges.
Séparation des responsabilités
Chaque couche a un rôle précis : le domaine porte les règles, l'application orchestre les cas d'usage, l'infrastructure gère la persistance et les I/O.
Pour approfondir ces principes, consultez notre retour d'experience sur la migration vers l'architecture hexagonale sur un projet Symfony en production.
Les avantages concrets pour votre projet
L'architecture hexagonale n'est pas un exercice académique. Elle apporte des bénéfices mesurables sur la maintenabilité, la testabilité et la capacité d'évolution de votre application.
Évolutivité maîtrisée
Ajouter une fonctionnalité métier ne nécessite pas de modifier l'infrastructure. Le domaine évolue indépendamment des choix techniques.
Migration facilitée
Changer de version Symfony, remplacer Doctrine par un autre ORM ou migrer vers une API : le noyau métier reste intact car il ne connaît pas ces outils.
Onboarding accéléré
Un nouveau développeur comprend les règles métier en lisant le domaine, sans devoir naviguer dans les controllers, les templates et la configuration Symfony.
Dette technique réduite
La séparation stricte des couches empêche le couplage accidentel. Le code reste modulaire même après des années de maintenance et d'évolutions.
Symfony Messenger joue un rôle clé dans cette architecture. Découvrez comment il devient la colonne vertébrale d'une architecture hexagonale en gérant commandes et événements.
Notre expérience terrain
Nous appliquons l'architecture hexagonale et le DDD sur des projets Symfony en production depuis plusieurs années. Voici comment nous procédons concrètement.
Migration progressive
Nous ne réécrivons jamais tout d'un coup. Nous extrayons progressivement le domaine métier des controllers Symfony existants, fonctionnalité par fonctionnalité, sans interruption de service.
CQRS et Messenger
Nous combinons l'architecture hexagonale avec CQRS et Symfony Messenger pour séparer lectures et écritures. Cette approche simplifie les flux complexes et prépare le terrain pour l'asynchrone.
Accompagnement des équipes
Nous formons vos développeurs aux principes du DDD et de l'architecture hexagonale. L'objectif est que votre équipe soit autonome pour maintenir et faire évoluer l'architecture.
Le choix entre micro-services et monolithe modulaire est une question que nous abordons systématiquement. L'architecture hexagonale s'applique aux deux approches, mais le monolithe modulaire reste souvent le meilleur point de départ. Pour évaluer la qualité architecturale de votre projet existant, notre audit de code PHP mesure le couplage, la séparation des couches et le respect des principes SOLID.
Quand adopter l'architecture hexagonale
L'architecture hexagonale n'est pas la réponse à tous les projets. Voici les situations où elle apporte une réelle valeur.
Règles métier complexes
Votre application gère des workflows métier avec de nombreuses conditions, validations et calculs. L'architecture hexagonale isole cette complexité dans un domaine testable.
Projet à longue durée de vie
L'application sera maintenue pendant des années par des équipes qui changeront. La séparation des couches garantit que le code reste compréhensible et évoluable.
Équipe pluridisciplinaire
Développeurs, product owners et experts métier collaborent étroitement. Le langage ubiquitaire du DDD facilite la communication entre tous les acteurs du projet.
Besoin d'indépendance technique
Vous anticipez un changement de framework, de base de données ou d'infrastructure. Le domaine isolé vous protège de ces évolutions techniques.
Prêt à structurer votre application Symfony ?
Que vous partiez de zéro ou que vous souhaitiez migrer une application existante vers l'architecture hexagonale, nous vous accompagnons à chaque étape.
Demander mon audit gratuitQuestions fréquentes
L'architecture hexagonale (ports et adaptateurs) et la clean architecture partagent le même principe fondamental : isoler le domaine métier des détails techniques. La différence est surtout terminologique. L'architecture hexagonale parle de ports et d'adaptateurs, la clean architecture de use cases et d'interactors. En pratique, sur un projet Symfony, les deux approches mènent à une structure très similaire.
Non. Pour un CRUD simple ou un back-office avec peu de logique métier, l'architecture hexagonale ajoute une complexité inutile. Elle prend tout son sens quand le domaine métier est riche, que le projet vivra longtemps ou que plusieurs équipes y contribuent. Nous vous aidons à évaluer si votre projet justifie cette approche.
La migration se fait progressivement. Nous commençons par identifier les règles métier enfouies dans les controllers et les services Symfony, puis nous les extrayons dans un domaine isolé. Chaque extraction est validée par des tests. Il n'est jamais nécessaire de tout réécrire d'un coup.
Symfony Messenger sert de bus de commandes et d'événements. Les commandes représentent les intentions métier (ports d'entrée), les handlers orchestrent les cas d'usage, et les adaptateurs (Doctrine, Mailer, API externes) sont injectés via les interfaces du domaine. Messenger devient la colonne vertébrale de l'architecture.
Doctrine reste un excellent choix, mais le domaine ne doit pas en dépendre directement. Nous définissons des interfaces de repository dans le domaine et les implémentons avec Doctrine dans la couche infrastructure. Ainsi, le domaine ignore complètement comment les données sont persistées.
Pour aller plus loin
- Audit Symfony gratuit , 30 minutes pour évaluer votre architecture actuelle
- Votre domaine ne devrait jamais connaître Symfony , le principe fondateur de l'architecture hexagonale
- Migration vers l'architecture hexagonale : retour de mission , un cas concret de migration en production
- Symfony Messenger, colonne vertébrale de l'archi hexagonale , le rôle de Messenger dans cette architecture
- Documentation officielle Symfony , référence technique du framework
Vous avez un projet en tête ?
Vous souhaitez réaliser un intranet, progiciel, une application entreprise ou un site internet complexe ? Efficience IT saura vous accompagner au mieux sur vos projets !