Le code ne reflète pas le métier
Les dossiers sont organisés par couches techniques, mais les règles, responsabilités et cas d'usage métier sont dispersés.
Des frontières métier qui rendent le code plus clair, pas plus cérémoniel.
LRJI aide les équipes à utiliser le DDD et l'architecture hexagonale pour clarifier les responsabilités, isoler le domaine, réduire le couplage et rendre les décisions d'architecture visibles dans le code.
L'objectif n'est pas d'imposer un vocabulaire. Le travail consiste à trouver les bonnes frontières, les bons ports/adapters et le bon niveau de discipline pour des équipes TypeScript, Node.js, NestJS ou full-stack qui doivent continuer à livrer.
Quand DDD et hexagonal deviennent utiles
Ces approches sont pertinentes quand elles corrigent un problème réel de compréhension, de couplage ou de delivery. Sinon, elles ajoutent surtout du vocabulaire.
Les frontières changent selon l'interlocuteur
Produit, engineering, data, support et intégrations ne décrivent pas les mêmes domaines ni les mêmes responsabilités.
Les adapters dictent le domaine
ORM, framework, broker, API externe ou fournisseur identity imposent leur structure aux règles métier.
Les tests sont difficiles à écrire sans infrastructure
Si tester une règle métier demande base, broker, HTTP ou framework complet, la frontière domaine est probablement trop faible.
Le vocabulaire DDD existe, mais pas les effets
On parle d'entities, services, repositories ou ports, mais la maintenabilité et la vitesse de changement ne s'améliorent pas.
Ce qui est clarifié
Le travail part du système réel. On garde ce qui aide la delivery et on élimine les abstractions qui ne paient pas leur coût.
- Bounded contexts et langage
- Identifier les domaines utiles, responsabilités, concepts ambigus et points de traduction entre équipes ou systèmes.
- Cas d'usage et domaine
- Exprimer les règles métier et workflows applicatifs sans dépendre directement du framework, de la base ou du transport.
- Ports, adapters et intégrations
- Définir les contrats entre domaine, infrastructure, API, messages, fournisseurs externes et stockage.
- Migration progressive
- Introduire la structure dans une codebase active par modules, tests, refactorings et premières frontières à fort effet.
La position LRJI
Le DDD est utile quand il améliore les décisions et le code. L'architecture hexagonale est utile quand elle protège le domaine sans rigidifier l'équipe.
Commencer par les tensions réelles
On ne découpe pas pour respecter un diagramme. On découpe là où le couplage, l'ambiguïté ou les changements fréquents coûtent cher.
Ne pas sacraliser les patterns
Entity, aggregate, repository, port ou adapter doivent résoudre un problème précis. Sinon, on retire.
Rendre les tests plus simples
Une bonne frontière permet de tester plus vite, plus localement et avec moins d'infrastructure obligatoire.
Protéger la delivery
L'introduction doit se faire par incréments utilisables, pas par réorganisation massive qui bloque la roadmap.
Comment l'accompagnement se déroule
Le format peut être diagnostic, cadrage ou accompagnement hands-on. Le fil reste le même : clarifier, prouver dans le code, puis transmettre.
- 01
Lire les flux métier
Cas d'usage, événements, règles, données, intégrations et responsabilités d'équipe sont cartographiés ensemble.
- 02
Choisir les premières frontières
Les zones à fort effet sont priorisées : celles qui changent souvent, cassent souvent ou bloquent la compréhension.
- 03
Prototyper la structure
Un module, un cas d'usage, un port ou un adapter servent de référence concrète plutôt qu'un document théorique.
- 04
Installer les règles d'équipe
Conventions, tests, exemples, ADRs ou revues guident l'équipe pour continuer sans dépendre du consultant.
Ce que l'équipe récupère
Les livrables doivent se voir dans la codebase et dans les décisions d'équipe.
- Bounded contexts, responsabilités et vocabulaire métier clarifiés.
- Structure applicative cible : cas d'usage, domaine, ports, adapters et modules.
- Exemples de code ou premières PRs montrant la structure attendue.
- Plan d'introduction progressif pour une codebase active ou legacy.
- Tests et contrats qui prouvent que les frontières améliorent la maintenabilité.
- ADRs, conventions ou règles de review pour garder la structure vivante.
Expériences pertinentes
Le DDD et l'hexagonal ont été utiles quand ils ont clarifié des plateformes réelles, pas quand ils ont ajouté du jargon.
Hexa
Banque : plateforme d'authentification critique
Architecture hexagonale autour de Keycloak, abstraction fournisseur et frontières applicatives plus testables.
Contrats
Luxe : frontières et contrats d'intégration
Responsabilités de systèmes et contrats d'échange clarifiés sur un écosystème d'identité client où les données ne pouvaient pas dériver.
7 -> 1
Retail : simplification par frontières plus nettes
Migration vers un déployable principal plus maintenable, avec réduction de coordination et meilleure cohérence de delivery.
Selon le besoin réel
DDD et hexagonal peuvent être le sujet central ou une partie d'un chantier architecture, migration ou event-driven.
FAQ
Est-ce réservé aux projets greenfield ?
Non. C'est souvent plus utile sur des produits existants, à condition de l'introduire progressivement et de cibler les zones où les frontières faibles coûtent vraiment cher.
Faut-il adopter strictement tout le vocabulaire DDD ?
Non. Le vocabulaire ne vaut que s'il améliore la communication et le code. LRJI privilégie les concepts qui produisent un effet mesurable sur la maintenabilité et la delivery.
Est-ce compatible avec NestJS ou d'autres frameworks ?
Oui. Le framework peut rester l'adapter d'entrée. Le point clé est de ne pas laisser le framework devenir le modèle domaine.
Apportez une zone du système où les frontières coûtent cher.
LRJI aide à transformer cette zone en modèle plus clair, structure applicative plus stable et trajectoire d'introduction que l'équipe peut réellement suivre.