Dans Clean Architecture de Robert C. Martin la règle de dépendance pointe strictement de la couche/de l'anneau le plus extérieur vers l'intérieur.
À titre d'exemple, un cadre d'injection de dépendance doit se trouver sur la couche la plus externe (cadres) pour permettre son remplacement.
Cependant, un cadre DI qui repose sur des attributs briserait clairement cela, car toute classe qui exigerait ces attributs aurait une dépendance sur le cadre. Par conséquent, une telle bibliothèque n'a pas pu être utilisée en suivant strictement la règle de dépendance.
Je rencontre le même problème avec les bibliothèques d'utilitaires, par exemple une bibliothèque mathématique ou une bibliothèque Rx fournissant des IObservables/Subjects.
La bibliothèque mathématique pourrait être enveloppée par un adaptateur pour la garder remplaçable - ce qui est logique, mais par exemple une entité fournissant le cadre pour les deux entités (couche la plus interne) ainsi que les systèmes (règles métier) et peut-être même l'interface utilisateur (présentateurs) simplement ne va pas bien avec cette conception.
Cependant, même pour la bibliothèque mathématique, le coût de l'ajout des interfaces pour Dependency Inversion + Adapter semble assez fou.
Suis-je en train de manquer quelque chose ou s'agit-il plus ou moins d'une règle qui enfreint généralement lorsque vous essayez d'implémenter Clean Architecture
.
Votre observation est correcte. Cependant, cela ne signifie pas que l'approche "Architecture propre" est erronée en général.
L'injection de dépendances est une technique majeure pour dissocier des éléments des "anneaux externes" comme la couche de base de données ou la couche réseau de la logique métier. Cela peut aider à rendre votre système plus découplé de nombreuses technologies sauf une: le framework DI lui-même (au cas où vous en utilisez un). Vous ne pouvez pas dissocier un système d'un framework DI en appliquant DI . Si vous voulez éviter une telle dépendance, la seule façon est de ne pas utiliser de framework DI du tout et de vous en tenir à Pure DI .
Cependant, même pour la bibliothèque mathématique, le coût de l'ajout des interfaces pour Dependency Inversion + Adapter semble assez fou.
Oui, les avantages de l'abstraction et du découplage ont toujours un coût. Donc, pour chaque bibliothèque ou outil tiers ou système externe que vous utilisez, vous devez évaluer la relation coûts/avantages de l'utiliser directement comme "infrastructure" de votre système, ou si vous devez fournir une couche d'abstraction.
Les tests unitaires sont un bon test décisif: pouvez-vous créer des tests unitaires simples et rapides pour votre logiciel sans couche d'abstraction supplémentaire?
pour une bibliothèque de mathématiques, la réponse sera probablement "oui" -> le découplage ne vaut peut-être pas la peine
pour une couche de base de données, la réponse sera souvent "non" -> le découplage en vaut probablement la peine
Cette approche peut vous aider à décider pour quelles parties du système vous vous en tenez à l '"architecture propre" et pour quelles parties vous feriez mieux de l'ignorer.
Le point de l'architecture propre est de rendre la technologie de l'application facilement remplaçable. Cela se fait au coût de la modification de la logique métier .
Donc, si vous faites une application dans laquelle une logique métier changeante (c'est-à-dire fournir de la valeur commerciale) est plus probable que des technologies changeantes, alors je suggérerais simplement d'ignorer complètement les idées d'architecture propre .
Cela étant dit, je ne suis pas non plus un fan des frameworks d'injection de dépendances. Cela interfère généralement avec votre conception, donc je le garderais complètement hors de l'application.