Cet article de Ihor Pal sur Medium explique le flux de traitement d'une requête HTTP dans une architecture propre (Clean Architecture). Il détaille comment une requête traverse les différentes couches (Domain, Use Cases, Interface Adapters, Frameworks) en montrant les structures de données échangées (DTOs, Entités, Value Objects) et l'orientation des dépendances. L'article illustre également la distinction entre les entités ORM et les entités de domaine, et met en lumière deux points clés d'inversion de dépendance. Un diagramme de flux complet et une structure de projet pratique en PHP/Symfony sont fournis pour clarifier le processus. L'objectif est de donner une vision dynamique de l'architecture propre, au-delà de la simple description statique des couches.
La "Clean Architecture" va bien au-delà d'une simple organisation de fichiers. Bien que souvent représentée par des couches comme Domain, Application, Infrastructure et UserInterface, son principe fondamental réside dans le sens des dépendances, qui doivent toujours pointer vers l'intérieur. Cela signifie que les règles métier (Domain) ne doivent pas dépendre des détails techniques (couches extérieures), permettant ainsi d'isoler la logique métier et de faciliter les tests et les évolutions du code. Cette approche, illustrée par les principes SOLID, favorise la flexibilité et la modularité, rendant le code plus résilient aux changements. Bien que l'arborescence des dossiers soit un outil pratique pour visualiser et organiser le code, l'essentiel est de se concentrer sur l'indépendance des couches métier vis-à-vis des dépendances techniques.
Tout est dans le titre
Cet article fait partie de ceux listés dans https://schlitt.info/blog/0784_best_of_posts_for_engineers.html
L'auteur préconise de ne pas utiliser des noms de classes en paramètre d'une méthode car cela casse le principe d'inversion de dépendance entre autres.
Un exemple de refactoring d'une classe pour appliquer le principe d'inversion de dépendance
Il s'agit de l'article à propos du "D" de SOLID :-)
Tout est dans le titre
L'auteur montre l'intérêt du principe d'inversion des dépendances pour tester efficacement des fonctionnalités sans se préoccuper de certains détails d'implémentation comme l'utilisation d'une base de données, etc.
Plein de conférences intéressantes :)
- L'état de la SPL dans PHP7
- Dependency Injection & Dependency Inversion
- API GraphQL
- Marier ReactJS et Symfony
- Object Calisthenics
- ReactPHP / PHP PM
- Tagua VM
- Opcode ? Mais à quoi ça sert ?
- PSRs : quoi, pourquoi et comment ?
- phpSpec : tests unitaires en Behavior Driven Development
- Les panama papers (Neo4j)
- Varnish : comment switcher sa prod sur un Raspberry Pi
De très bons conseils sur l'architecture logicielle, ce qu'elle est et ce qu'elle n'est pas