"Clean Architecture" de Bob Martin est-il une règle de base pour toutes les architectures ou n'est-ce qu'une des options?
J'ai vraiment aimé les concepts de la vidéo The Principles of Clean Architecture by Oncle Bob Martin . Mais j'ai l'impression que ce modèle est comme une combinaison de modèles Abstract Factory et Builder à la base.
C'est une façon d'écrire de bons programmes mais pas la seule.
Rails et reactjs sont 2 frameworks qui viennent à l'esprit qui ne favorisent pas ce type d'architecture propre. Rails s'attend à ce que votre logique métier soit dans les modèles ( FatModels et SkinnyControllers ), et réagisse à l'intérieur de vos composants. Les deux approches couplent étroitement la logique métier et code cadre.
Je ne trouve rien de mal dans aucune des 3 façons. C'est un appel au jugement de choisir n'importe qui.
Mais dans la vidéo, je pense qu'il suggère qu'une architecture propre devrait avoir une frontière claire entre la logique métier et les frameworks. Les frameworks (web, Android, etc.) doivent être des plugins qui se connectent à à la logique métier. Il se moque même subtilement Rails dans la vidéo.
Donc, Est-ce que "Clean Architecture" de Bob Martin est une règle de base pour toutes les architectures ou est-ce juste une des options?
Bien que "l'architecture propre" soit correcte et présente de nombreux avantages, il est important de se rappeler que:
L'architecture propre est en grande partie le re-branding et l'évolution de Robert C. Martin d'approches connexes comme l'architecture Onion de Jeffrey Palermo (2008) et l'architecture hexagonale ("Ports et adaptateurs") par Alistair Cockburn et autres (<2008).
Différents problèmes ont des exigences différentes. L'architecture propre et les approches connexes transforment le découplage, la flexibilité et l'inversion des dépendances jusqu'à onze, mais sacrifient la simplicité. Ce n'est pas toujours une bonne affaire.
Le précurseur de ces architectures est le modèle MVC classique de Smalltalk. Cela démêle le modèle de l'interface utilisateur (contrôleur et vue), de sorte que le modèle ne dépend pas de l'interface utilisateur. Il existe de nombreuses variantes de MVC comme MVP, MVVM,….
Les systèmes plus complexes n'ont pas une seule interface utilisateur, mais éventuellement plusieurs interfaces utilisateur. De nombreuses applications choisissent d'offrir une REST qui peut être utilisée par n'importe quelle interface utilisateur, telle qu'une application Web ou une application mobile. Cela isole la logique métier du serveur de ces interfaces utilisateur, donc le serveur ne se soucie pas du type d'application qui y accède.
En règle générale, le serveur dépend toujours de services principaux tels que des bases de données ou des fournisseurs tiers. C'est parfaitement bien, et conduit à une architecture simple en couches.
L'architecture hexagonale va plus loin et cesse de faire une distinction entre frontend et backend. Tout système externe peut être une entrée (source de données) ou une sortie. Notre système central définit les interfaces (ports) nécessaires et nous créons des adaptateurs pour tous les systèmes externes.
Une approche classique pour un découplage fort est une architecture orientée services (SOA), où tous les services publient des événements et consomment des événements à partir d'un bus de messages partagé. Une approche similaire a ensuite été popularisée par les microservices.
Toutes ces approches ont avantages, telles que faciliter tester le système isolément (en remplaçant tous les systèmes externes avec lesquels il s'interface par des implémentations simulées). Ils permettent de fournir plus facilement plusieurs implémentations pour un type de service (par exemple, ajouter un deuxième processeur de paiement), ou échanger l'implémentation d'un service (par exemple, passer d'un Base de données Oracle vers PostgreSQL, ou en réécrivant un service Python dans Go).
Mais ces architectures sont la Ferrari des architectures: chères, et la plupart des gens n'en ont pas besoin. La flexibilité supplémentaire de l'architecture propre, etc. se fait au prix d'une complexité accrue. De nombreuses applications et notamment les webapps CRUD n'en bénéficient pas. Il est logique d'isoler les choses qui pourraient changer, par exemple en utilisant des modèles pour générer du HTML. Il est moins logique d'isoler des choses qui ne changeront probablement pas, par exemple la base de données de sauvegarde. Ce qui est susceptible de changer dépend du contexte et des besoins de l'entreprise.
Les cadres font des hypothèses sur ce qui va changer. Par exemple. React a tendance à supposer que la conception et le comportement d'un composant changent ensemble, donc il n'est pas logique de les séparer. Peu de frameworks supposent que vous voudrez peut-être changer le framework. En tant que tels, les frameworks présentent un certain degré de blocage. Par exemple, la dépendance de Rail à l'égard du modèle d'enregistrement actif (très avisé!) rend difficile, voire impossible, le changement de votre stratégie d'accès aux données au modèle de dépôt (souvent supérieur). Si vos attentes de changement ne correspondent pas le cadre, l'utilisation d'un cadre différent pourrait être mieux. De nombreux autres cadres Web ne font aucune hypothèse sur l'accès aux données.
J'ai vraiment aimé les concepts de la vidéo Les principes de l'architecture propre de l'oncle Bob Martin. Mais j'ai l'impression que ce modèle est comme une combinaison de modèles Abstract Factory et Builder à la base.
Pas même près.
Quand vous regardez ceci:
Vous regardez la conception d'un graphe d'objet. Cela dicte ce qui sait quoi. Ce qui manque dans cette histoire, c'est comment ce graphe d'objet a été construit. Désolé mais vous ne le trouverez pas ici. Il n'y a aucune mention de construction.
Vous pouvez construire tout cela sans usines ni constructeurs abstraits. Je sais parce que je l'ai fait . Je n'ai même pas voulu les éviter. Je les aime. Je n'ai tout simplement pas eu besoin d'eux. J'ai juste utilisé le passage de référence. Injection de dépendance est le terme de fantaisie pour cela.
En fait, je pourrais construire tout ce que vous voyez dans ce diagramme en principal. Ensuite, il suffit d'appeler une méthode sur un objet pour démarrer le tout.
Maintenant, les choses doivent exister avant de pouvoir les pousser dans d'autres choses. J'ai exploré cela ici et lui ai donné ce joli petit diagramme:
Et vous pouvez construire tout cela sans même quitter main().
Je recommanderais d'utiliser des constructeurs et des usines lorsque vous souhaitez diviser un tas de code de construction procédural en morceaux conceptuels de la taille d'une bouchée. Mais il n'y a rien dans l'architecture propre ou dans aucune des autres architectures à la mode qui exige que vous le fassiez. Donc, si vous voulez vous en tenir à main(), très bien. S'il vous plaît, ayez pitié .
"Clean Architecture" de Bob Martin est-il une règle de base pour toutes les architectures ou n'est-ce qu'une des options?
Je considère l'architecture propre comme un mot à la mode utilisé pour conduire les gens vers un blog et un livre. Ce blog et ce livre ont de très bonnes explications sur des architectures anciennes très similaires avec des noms plus anciens utilisés pour conduire les gens vers des blogs et des livres plus anciens. Plus précisément Oignon ainsi que les ports et adaptateurs. Aucune de ces options n'est la seule dont vous disposez.
J'aime Oncle Bob parce qu'il est un conférencier et un auteur génial. Il me fait penser à des choses que je n'aurais pas autrement. Mais si vous laissez cela vous transformer en un fanatique religieux qui insiste sur le fait que tout doit être fait à sa manière, vous constaterez rapidement que la mise à jour de la documentation est la plus proche, je vous laisserai accéder à mon code.
Les architectures de mots à la mode sont utiles lorsque vous avez du code de longue durée qui doit persister pendant que le monde change autour de lui. C'est alors que ça brille. Si le monde est stable par rapport au code, alors vous faites des choses fantaisistes sans raison valable.
Peu importe à quel point quelque chose est génial, il y a un contexte dans lequel vous pouvez le mettre qui le rendra absurde. Désolé, ce n'est pas non plus une solution miracle.
Mais dans la vidéo, je pense qu'il suggère qu'une architecture propre devrait avoir une frontière claire entre la logique métier et les frameworks. Les frameworks (web, Android, etc.) doivent être des plugins qui se connectent à la logique métier. Il se moque même subtilement Rails dans la vidéo.
Tu as raison. Il fait. Oncle Bob pense que les frameworks peuvent être traités comme des bibliothèques. Et ils le peuvent. Mais même cette décision vous coûte quelque chose.
Ce que M. Martin essaie de préserver, c'est un espace où votre langage généraliste est toujours général. Vous abandonnez cela lorsque vous diffusez un cadre partout. Lorsque vous faites cela, vous vous dirigez vers le chemin de la transformation de votre langue en quelque chose appelé une langue spécifique au domaine. HTML est un langage spécifique au domaine. Il fait très bien son travail mais il y a d'autres emplois qu'il ne peut pas faire du tout.
Tant que vos besoins seront anticipés par le cadre, les choses se passeront très bien. C'est agréable d'avoir vos besoins anticipés. Il vous met dans une boîte qui garde les choses simples. Comprenez simplement ce que vous abandonnez pour l'obtenir. Si vous diffusez Spring partout, vous ne pouvez plus l'annoncer comme un travail Java. C'est un travail Java/Spring. Je pourrais dire la même chose à propos de Ruby = et Rails mais Rails a mangé le déjeuner de Ruby il y a longtemps).
Pour citer la vidéo:
"Vous ne voulez pas faire de fusion et publipostage en SQL."
suivi par:
"J'ai en fait vu une procédure stockée SQL qui était une opération de fusion et publipostage complète"
L'architecture, comme la fusion et le publipostage, n'est qu'une option parmi tant d'autres.
Ce qui n'est pas facultatif, ce sont les problèmes que l'architecture essaie de résoudre.
Si vous comprenez les problèmes provoqués par le publipostage SQL par rapport à d'autres solutions, votre choix architectural sera informé et même si vous êtes obligé de choisir de `` mauvaises '' solutions, vous serez conscient et atténuerez leurs lacunes.
Si vous suivez un style architectural simplement parce qu'il est bien pensé, vous risquez de faire des erreurs et de rencontrer les mêmes problèmes.
"L'architecture propre" n'est certainement "qu'une" des options. Je dirais que c'est l'une des mauvaises options pour la plupart des projets, en particulier pour les projets orientés objet.
Voici une analyse phrase par phrase de l'article de l'oncle Bob sur l'architecture propre avec les raisons de la déclaration ci-dessus:
L'architecture propre est un ensemble de principes et de modèles pour répondre à un certain nombre de symptômes courants auxquels les organisations de développement de logiciels sont souvent confrontées au cours de la durée de vie de la création d'applications complexes. M. Martin fait de grands efforts dans le livre pour identifier les symptômes et les causes profondes sur la base de sa vaste expérience dans le domaine, et pour clarifier le rôle de l'architecture dans l'atténuation de ces préoccupations.
Cependant, ce n'est pas une règle de base, ni une panacée à tous les maux. Si vous lisez le livre, vous comprendrez mieux si/quand/comment appliquer les principes et les schémas qu'il préconise (et les compromis impliqués). Si vous n'avez pas lu le livre, vous risquez de faire des hypothèses, des applications, des jugements et des déclarations incorrects sur la base d'informations incomplètes.