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 le 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. L'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 partir 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 bonne taille. Mais il n'y a rien dans une architecture propre ou dans aucune autre architecture à la mode qui exige que vous le fassiez. Donc, si vous voulez rester 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 des 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 anticipé vos besoins. 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 le publier comme un travail Java. C'est un travail Java / Spring. Je pourrais dire la même chose à propos de Ruby and Rails, mais Rails a mangé le déjeuner de Ruby il y a longtemps.