§ 01
Métier isolé
Les règles métier écrites en PHP pur, sans dépendance au framework ni à la base. Tests exécutés en millisecondes.
- Objets métier riches
- Règles protégées
- Indépendant du framework
- Événements métier
ARCHITECTURE HEXAGONALE SYMFONY
Une architecture qui tolère le changement.
Une architecture où le métier est isolé du framework et de la base de données, appliquée avec pragmatisme. Un noyau métier indépendant des détails techniques, des tests rapides, des montées de version fluides — l'approche que j'utilise sur tous les projets dont la durée de vie dépasse 3 ans.
§ 01 — Le problème
Le problème.
Sans expert
- Métier mélangé à la base — Impossible de tester une règle sans lancer une base de données.
- Dépendance aux prestataires — Changer de service de paiement oblige à modifier 15 fichiers différents.
- Refontes douloureuses — Chaque évolution structurelle fait casser toutes les couches à la fois.
- Tests lents — La suite complète prend 15 minutes parce qu'elle dépend du framework.
- Prise en main interminable — Un nouveau développeur met 3 semaines à comprendre où « habite » une règle métier.
Avec Vulcain
- Trois couches nettement séparées : le métier
- La coordination applicative
- Et les détails techniques. le métier ne connaît ni symfony
- Ni la base de données
- Ni l'http. des <em>points de branchement</em> bien définis permettent de remplacer un prestataire externe sans toucher aux règles métier.
§ 02 — Ce qui est livré
Ce qui est livré.
§ 02
Couche de coordination
Les cas d'usage (passer commande, annuler, facturer) sont coordonnés sans mélanger de règles métier. Chaque action est transactionnelle.
- Cas d'usage clairs
- Séparation lecture/écriture
- Transactions
- Orchestration propre
§ 03
Points de branchement
Le métier déclare ce dont il a besoin (« envoyer un email », « sauvegarder une commande ») ; la technique (base, API externe, fichier) se branche sans toucher au métier.
- Interfaces claires
- Base de données remplaçable
- API externes remplaçables
- Doubles rapides pour tests
§ 04
Assemblage des composants
Composants immuables, assemblage par Symfony. Composition plutôt qu'héritage : chaque classe fait une seule chose, bien.
- Classes immuables
- Assemblage explicite
- Composition maîtrisée
- Responsabilité unique
§ 05
Tests rapides
Le métier se teste sans lancer le framework, sans base. La suite complète tourne en moins de 30 secondes sur un projet moyen.
- Tests métier < 1 ms
- Tests avec doubles en mémoire
- Tests d'intégration ciblés
- Pyramide de tests
§ 06
Décisions documentées
Chaque décision structurante (choix d'approche, dépendance introduite, compromis accepté) est consignée dans un document versionné, lisible par un futur repreneur.
- Décisions tracées
- Schémas d'architecture
- Glossaire métier
- Périmètres métier délimités
src/Domain/Order/Order.php
php
<?php
declare(strict_types=1);
namespace App\Domain\Order;
// Entité riche : les invariants métier sont protégés par le constructeur
// et les méthodes de transition d'état. Aucune annotation Doctrine.
final class Order
{
/** @var list<OrderItem> */
private array $items;
private function __construct(
private readonly OrderId $id,
private readonly CustomerId $customerId,
array $items,
private OrderStatus $status,
) {
if ($items === []) {
throw new EmptyOrder();
}
$this->items = $items;
}
/** @param list<OrderItem> $items */
public static function place(CustomerId $customer, array $items): self
{
return new self(OrderId::generate(), $customer, $items, OrderStatus::Placed);
}
public function confirm(): void
{
if ($this->status !== OrderStatus::Placed) {
throw new InvalidTransition($this->status, 'confirm');
}
$this->status = OrderStatus::Confirmed;
}
}Une commande, écrite uniquement en PHP pur : aucune dépendance au framework, aucune référence à la base. Les règles métier vivent ici et nulle part ailleurs.
§ 04 — Tarifs & délais
§ 01
Atelier architecture
Pour poser les fondations : périmètres métier, règles, décisions d'architecture. Livrable : squelette de code + documentation.
- Cartographie métier collective
- Périmètres délimités
- Décisions documentées
- Squelette de code
- Formation équipe
§ 02
Refonte progressive
Introduction de la nouvelle architecture dans une base existante, module par module, sans geler votre activité.
- Audit existant
- Stratégie de remplacement progressif
- Premiers modules migrés
- Tests de caractérisation
- Suivi 3 mois
§ 03
Accompagnement équipe
Coaching architectural régulier : revue de code, programmation en binôme, montée en compétence de vos développeurs.
- Revue de code hebdomadaire
- Programmation en binôme
- Atelier mensuel
- Documentation à jour
- Facturation au temps passé
Tarifs sur devis après cadrage · forfait ou régie selon le format
§ 05 — Cas client · CRM immobilier · 4 ans d'exploitation
HomeHunters
Plateforme de gestion de 3 000+ biens, refondue avec un métier isolé du framework. Quatre ans plus tard, zéro régression métier lors des montées Symfony et ajout de fonctionnalités sans casser les anciennes.
- Symfony 5
- Doctrine
- PHPUnit
- Docker
3 000+
Biens gérés
0
Régression depuis refonte
< 30 s
Suite tests complète
§ 04 — Questions fréquentes
Questions sur l' architecture .
§ 01 Cette architecture, c'est pas sur-dimensionné pour un projet Symfony ?
Pour une application simple, oui. Pour une application métier avec règles complexes, intégrations multiples, durée de vie de plus de 3 ans, c'est un investissement qui rembourse plusieurs fois. On en discute projet par projet.
§ 02 Vous utilisez l'outillage Symfony ou vous faites tout à la main ?
L'outillage Symfony pour la plomberie (configuration, routes, assemblage). Fait-main pour l'organisation métier — les générateurs automatiques produisent un squelette qui mélange tout.
§ 03 La base Doctrine fonctionne avec cette architecture ?
Très bien, à condition de la cantonner à la couche technique. Les objets métier ne contiennent aucune référence à Doctrine — la correspondance avec la base se fait séparément.
§ 04 Comment vous gérez les transactions ?
Une transaction englobe chaque cas d'usage côté applicatif. Les événements métier (facture créée, commande confirmée) sont publiés seulement après validation réussie, jamais entre-temps.
§ 05 Toutes les approches avancées en même temps ?
Non. L'approche métier isolé sur tous les projets. La séparation lecture/écriture seulement quand les deux usages divergent fortement. La traçabilité complète des événements uniquement quand le métier l'exige (audit, historique).
§ 06 Vos tests dépendent-ils de la base de données ?
Les tests métier : non. Les tests applicatifs : non (doubles en mémoire). Les tests d'intégration sur la vraie base : oui, mais c'est une minorité et on les isole.
§ 06 — Voir aussi
§ 08 — Mettre la forge au travail
15 minutes pour savoir
15 minutes pour savoir
si on peut forger ensemble.
Un appel, pas un formulaire de 12 champs. Vous m'expliquez votre besoin, je vous dis honnêtement si je suis la bonne personne, on repart avec une prochaine étape claire.
-
01
Compte-rendu écrit et estimation envoyés sous 24 h.
-
02
Aucun engagement. Aucune relance commerciale.
-
03
Si ce n'est pas pour moi, je vous oriente vers un confrère.