L’auteur explique comment Domain-Driven Design (DDD) a révolutionné sa vision de l’architecture logicielle, notamment pour les agents IA. Après des années de routine en développement, il découvre ce concept en lisant Domain-Driven Design d’Eric Evans, ce qui transforme sa manière d’aborder la complexité des systèmes. Son expérience précédente avec des microservices mal conçus, où les services manquaient de sens métier, l’a poussé à chercher une approche plus structurée.
Le livre l’a confronté à une réflexion approfondie sur la modélisation du domaine, où chaque détail (noms de classes, relations, effets de bord) devient crucial. Cette approche l’a ramené aux fondamentaux de la programmation orientée objet, avec une attention accrue à la clarté et à la cohérence du code. Il souligne que DDD a comblé un vide entre le développement et la compréhension du métier, contrairement à sa vision initiale où ces deux aspects étaient dissociés.
L’article explique comment structurer une architecture logicielle en trois couches (Domaine, Application, Infrastructure) en respectant la règle d’or centripète et le principe d’inversion de dépendance (DIP). L’idée centrale est que les dépendances doivent toujours aller du plus concret (infrastructure) vers le plus abstrait (domaine), jamais l’inverse, afin de préserver l’indépendance et la testabilité de la logique métier.
Le domaine concentre les règles métier, les agrégats (unités cohérentes comme un dossier de demande de subvention) et les value objects (objets immuables sans identité propre). Il définit des ports (interfaces) pour les besoins externes, sans jamais dépendre d’outils comme Doctrine ou Symfony. La couche applicative gère les cas d’usage via des handlers qui orchestrent les flux, tandis que l’infrastructure implémente concrètement ces ports (ex : adaptateurs pour Doctrine ou S3), sans jamais être importée par les couches supérieures.
Cette approche garantit que le métier reste isolé des détails techniques. Par exemple, un handler utilise DepositRequestRepositoryInterface (port défini dans le domaine) sans connaître son implémentation (DoctrineDepositRequestRepository en infrastructure). Ainsi, les changements d’outils n’affectent pas la logique métier, et les imports PHP respectent strictement la hiérarchie des couches.
Tout est dans le titre