Une introduction rapide à l'architecture propre

Dans un projet open source auquel j'ai commencé à contribuer, le concept «d'architecture propre» m'a été présenté.

Tout d'abord, c'était assez accablant, mais après quelques lectures, cela avait du sens. J'ai pensé que cela pourrait être utile pour les autres si j'écrivais mes pensées.

Table des matières

  • Représentations visuelles
  • Le concept - présenté sous forme de puces
  • Exemple de code
  • Ressources

Représentations visuelles

Je pense qu'il est toujours bon de commencer par une certaine visualisation.

Voici les images les plus courantes de ce concept.

Le concept - présenté sous forme de puces

Extrait de Source et crédit: Mattia Battiston, sous CC BY 4.0

La valeur qu'elle peut apporter

  • Une stratégie de test efficace qui suit la pyramide des tests
  • Les cadres sont isolés dans des modules individuels. Quand (pas si) nous changeons d'avis, nous n'avons à faire un changement qu'à un seul endroit. L'application a des cas d'utilisation plutôt que d'être liée à un système CRUD
  • Une architecture hurlante, c'est-à-dire qu'elle crie son utilisation prévue. Lorsque vous regardez la structure du package, vous avez une idée de ce que fait l'application plutôt que de voir les détails techniques
  • Toute la logique métier est dans un cas d'utilisation, elle est donc facile à trouver et non dupliquée ailleurs
  • Difficile de faire la mauvaise chose car les modules appliquent les dépendances de compilation. Si vous essayez d'utiliser quelque chose que vous n'êtes pas censé faire, l'application ne compile pas
  • Il est toujours prêt à être déployé en laissant le câblage de l'objet pour la fin. Ou en utilisant des indicateurs de fonctionnalité, nous bénéficions ainsi de tous les avantages de l'intégration continue
  • Plusieurs travaux sur des histoires afin que différentes paires puissent facilement travailler sur la même histoire en même temps pour la terminer plus rapidement
  • Bon monolithe avec des cas d'utilisation clairs que vous pouvez diviser en microservices plus tard, une fois que vous en aurez appris plus sur eux

Entités

  • Représentez votre objet de domaine
  • Appliquer uniquement la logique qui est applicable en général à l'ensemble de l'entité (par exemple, valider le format d'un nom d'hôte)
  • Objets simples: pas de cadres, pas d'annotations

Cas d'utilisation

  • Représentez vos actions commerciales: c'est ce que vous pouvez faire avec l'application. Attendez-vous à un cas d'utilisation pour chaque action commerciale
  • Logique métier pure, code brut (sauf peut-être certaines bibliothèques d'utils)
  • Le cas d'utilisation ne sait pas qui l'a déclenché et comment les résultats vont être présentés (par exemple, peuvent être sur une page Web, ou - renvoyés au format JSON, ou simplement enregistrés, etc.).
  • Lève des exceptions commerciales

Interfaces / Adaptateurs

  • Récupérez et stockez des données depuis et vers un certain nombre de sources (base de données, périphériques réseau, système de fichiers, tiers, etc.)
  • Définissez des interfaces pour les données dont ils ont besoin afin d'appliquer une certaine logique. Un ou plusieurs fournisseurs de données implémenteront l'interface, mais le cas d'utilisation ne sait pas d'où proviennent les données
  • Implémenter les interfaces définies par le cas d'utilisation
  • Il existe des moyens d'interagir avec l'application et impliquent généralement un mécanisme de livraison (par exemple, des API REST, des tâches planifiées, une interface graphique, d'autres systèmes)
  • Déclenchez un cas d'utilisation et convertissez le résultat au format approprié pour le mécanisme de livraison
  • le contrôleur pour un MVC

Interfaces externes

  • Utilisez le cadre le plus approprié (ils seront de toute façon isolés ici)

Exemple de code

Voir la structure sur GitHub.

Tout d'abord, il est important de comprendre qu'une architecture propre est un ensemble de principes d'organisation. Donc, tout est ouvert à des ajustements personnels tant que les idées fondamentales sont conservées intactes. Le référentiel lié est une fourchette du projet original qui m'a amené cette idée de conception d'architecture. N'hésitez pas à consulter également le projet original, car il reflète d'autres améliorations.

Le dossier webminer est structuré en couches de base:

  1. entités
  2. use_cases
  3. interfaces_adapters
  4. interfaces_externes

Il doit refléter l'approche très basique du modèle de conception.

  • À partir de entities, vous pouvez voir que le modèle de base de ce projet est learxiv_document
  • Le dossier suivant, use_casesmontre notre cas d'utilisation, à savoir demander la page arxiv
  • Après cela, nous parcourons le interface_adaptersdossier qui fournit des adaptateurs pour les demandes de traitement dans une application REST ou pour la sérialisation
  • La dernière et dernière couche est external_interfaces. C'est là que nous utilisons le serveur flask pour implémenter la fonctionnalité REST

Toutes ces couches dépendent des couches centrales, mais pas l'inverse.

Une remarque importante: ce n'est pas correctement implémenté à 100% dans le référentiel.

Pourquoi? Parce que les cas d'utilisation sont en fait différents. En réalité, le principal cas d'utilisation est de fournir les données structurées. Un autre cas d'utilisation est d'obtenir les données de la page arxiv.

Avez-vous repéré cette erreur dans l'architecture? Si oui, félicitations! Non seulement vous avez apporté suffisamment de curiosité à cet article, mais vous comprenez probablement assez bien les principes pour construire votre propre cas et appliquer les concepts dans la réalité!

Êtes-vous d'accord? Si non, pourquoi? Merci d'avoir lu mon article! N'hésitez pas à laisser vos commentaires!

Ressources

Voici quelques articles que j'ai trouvés utiles pour comprendre le concept d '«architecture propre»:

  • //8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html
  • //www.codingblocks.net/podcast/clean-architecture-make-your-architecture-scream/
  • //github.com/mattia-battiston/clean-architecture-example
  • //medium.com/@tiagoflores_23976/how-choose-the-appropriate-ios-architecture-mvc-mvp-mvvm-viper-or-clean-architecture-2d1e9b87d48
  • //de.slideshare.net/HimanshuDudhat1/mvp-clean-architecture
  • //softwareengineering.stackexchange.com/questions/336677/what-is-the-difference-b between-mvp-and-clean-architecture
  • //engineering.21buttons.com/clean-architecture-in-django-d326a4ab86a9
  • //gist.github.com/ygrenzinger/14812a56b9221c9feca0b3621518635b
  • //medium.freecodecamp.org/how-to-write-robust-apps-consistently-with-the-clean-architecture-9bdca93e17b
  • //marconijr.com/posts/clean-architecture-practice/

Daniel est un LL.M. étudiant en droit des affaires, travaillant comme ingénieur logiciel et organisateur d'événements liés à la technologie à Vienne. Ses efforts actuels d'apprentissage personnel se concentrent sur l'apprentissage automatique.

Connectez-vous sur:

  • LinkedIn
  • Github
  • Moyen
  • Twitter
  • Steemit
  • Hashnode