Architecture Patterns with Python

Nous travaillons tous deux pour MADE.com, une entreprise de commerce électronique européenne qui vend des meubles en ligne ; là-bas, nous appliquons les techniques de ce livre pour construire des systèmes distribués qui modélisent les problèmes métier du monde réel. Notre domaine d’exemple est le premier système que Bob a construit pour MADE, et ce livre est une tentative de mettre par écrit tout ce truc que nous devons enseigner aux nouveaux programmeurs lorsqu’ils rejoignent l’une de nos équipes.

MADE.com gère une chaîne d’approvisionnement mondiale de partenaires de fret et de fabricants. Pour maintenir les coûts bas, nous essayons d’optimiser la livraison de stock vers nos entrepôts afin de ne pas avoir de marchandises invendues qui traînent.

Idéalement, le canapé que vous voulez acheter arrivera au port le jour même où vous décidez de l’acheter, et nous le livrerons directement chez vous sans jamais le stocker. Avoir le bon timing est un exercice d’équilibre délicat lorsque les marchandises prennent trois mois pour arriver par porte-conteneurs. En chemin, les choses se cassent ou sont endommagées par l’eau, les tempêtes causent des retards inattendus, les partenaires logistiques manipulent mal les marchandises, la paperasse disparaît, les clients changent d’avis et modifient leurs commandes, et ainsi de suite.

Nous résolvons ces problèmes en construisant des logiciels intelligents représentant les types d’opérations qui se déroulent dans le monde réel afin de pouvoir automatiser autant que possible l’activité.

Si vous lisez ce livre, nous n’avons probablement pas besoin de vous convaincre que Python est génial, donc la vraie question est "Pourquoi la communauté Python a-t-elle besoin d’un livre comme celui-ci ?" La réponse concerne la popularité et la maturité de Python : bien que Python soit probablement le langage de programmation à la croissance la plus rapide au monde et s’approche du sommet des tableaux de popularité absolue, il ne fait que commencer à prendre en charge les types de problèmes sur lesquels le monde C# et Java travaille depuis des années. Les startups deviennent de vraies entreprises ; les applications web et les automatisations scriptées deviennent (chuchotons-le) des logiciels d’entreprise.

Dans le monde Python, nous citons souvent le Zen de Python : "Il devrait y avoir une—​et de préférence une seule—​manière évidente de le faire."^[1] Malheureusement, à mesure que la taille du projet augmente, la manière la plus évidente de faire les choses n’est pas toujours celle qui vous aide à gérer la complexité et l’évolution des exigences.

Aucune des techniques et patterns dont nous discutons dans ce livre n’est nouvelle, mais elles sont pour la plupart nouvelles dans le monde Python. Et ce livre n’est pas un remplacement des classiques du domaine tels que le Domain-Driven Design d’Eric Evans ou les Patterns of Enterprise Application Architecture de Martin Fowler (tous deux publiés par Addison-Wesley Professional)—que nous référençons souvent et vous encourageons à aller lire.

Mais tous les exemples de code classiques de la littérature ont tendance à être écrits en Java ou C++/#, et si vous êtes une personne Python et n’avez pas utilisé l’un de ces langages depuis longtemps (ou même jamais), ces listings de code peuvent être assez…​éprouvants. Il y a une raison pour laquelle la dernière édition de cet autre texte classique, le Refactoring de Fowler (Addison-Wesley Professional), est en JavaScript.

Voici quelques éléments que nous supposons vous concernant, cher lecteur :

Nous structurons nos explorations des patterns architecturaux autour d’une application d’exemple, en la construisant chapitre par chapitre. Nous utilisons le TDD au travail, donc nous avons tendance à montrer d’abord les listings de tests, suivis de l’implémentation. Si vous n’êtes pas habitué à travailler en test-first, cela peut sembler un peu étrange au début, mais nous espérons que vous vous habituerez bientôt à voir le code "être utilisé" (c’est-à-dire, de l’extérieur) avant de voir comment il est construit à l’intérieur.

Nous utilisons certains frameworks et technologies Python spécifiques, notamment Flask, SQLAlchemy, et pytest, ainsi que Docker et Redis. Si vous êtes déjà familier avec eux, cela n’entravera pas, mais nous ne pensons pas que ce soit requis. L’un de nos principaux objectifs avec ce livre est de construire une architecture pour laquelle les choix technologiques spécifiques deviennent des détails d’implémentation mineurs.

Le livre est divisé en deux parties ; voici un aperçu des sujets que nous couvrirons et des chapitres dans lesquels ils se trouvent.

Vous lisez un livre, mais vous serez probablement d’accord avec nous lorsque nous disons que la meilleure façon d’apprendre sur le code est de coder. Nous avons appris la majeure partie de ce que nous savons en faisant du pair programming avec des gens, en écrivant du code avec eux, et en apprenant en faisant, et nous aimerions recréer cette expérience autant que possible pour vous dans ce livre.

En conséquence, nous avons structuré le livre autour d’un seul projet d’exemple (bien que nous lancions parfois d’autres exemples). Nous construirons ce projet au fur et à mesure de la progression des chapitres, comme si vous aviez fait du pair programming avec nous et que nous expliquions ce que nous faisons et pourquoi à chaque étape.

Mais pour vraiment saisir ces patterns, vous devez manipuler le code et avoir une idée de comment il fonctionne. Vous trouverez tout le code sur GitHub ; chaque chapitre a sa propre branche. Vous pouvez trouver une liste des branches sur GitHub également.

Particulièrement si vous avez l’intention d’appliquer certains de ces patterns dans vos propres projets, travailler sur un exemple simple est un excellent moyen de pratiquer en toute sécurité.

Le code (et la version en ligne du livre) est sous licence Creative Commons CC BY-NC-ND, ce qui signifie que vous êtes libre de le copier et de le partager avec qui vous voulez, à des fins non commerciales, tant que vous donnez l’attribution. Si vous voulez réutiliser une partie du contenu de ce livre et que vous avez des inquiétudes concernant la licence, contactez O’Reilly à permissions@oreilly.com.

L’édition imprimée est sous une licence différente ; veuillez consulter la page de copyright.

Les conventions typographiques suivantes sont utilisées dans ce livre :

Notre réseau unique d’experts et d’innovateurs partagent leurs connaissances et leur expertise à travers des livres, des articles, des conférences et notre plateforme d’apprentissage en ligne. La plateforme d’apprentissage en ligne d’O’Reilly vous donne un accès à la demande à des cours de formation en direct, des parcours d’apprentissage approfondis, des environnements de codage interactifs, et une vaste collection de textes et vidéos d’O’Reilly et de plus de 200 autres éditeurs. Pour plus d’informations, veuillez visiter http://oreilly.com.

Veuillez adresser les commentaires et questions concernant ce livre à l’éditeur :

Nous avons une page web pour ce livre, où nous listons les errata, exemples et toute information additionnelle. Vous pouvez accéder à cette page à https://oreil.ly/architecture-patterns-python.

Envoyez un email à bookquestions@oreilly.com pour commenter ou poser des questions techniques sur ce livre.

Pour plus d’informations sur nos livres, cours, conférences et actualités, consultez notre site web à http://www.oreilly.com.

Trouvez-nous sur Facebook : http://facebook.com/oreilly

Suivez-nous sur Twitter : http://twitter.com/oreillymedia

Regardez-nous sur YouTube : http://www.youtube.com/oreillymedia

À nos relecteurs techniques, David Seddon, Ed Jung, et Hynek Schlawack : nous ne vous méritons absolument pas. Vous êtes tous incroyablement dévoués, consciencieux, et rigoureux. Chacun de vous est immensément intelligent, et vos différents points de vue ont été à la fois utiles et complémentaires les uns aux autres. Merci du fond de nos cœurs.

Gigantesques remerciements également à tous nos lecteurs jusqu’à présent pour leurs commentaires et suggestions : Ian Cooper, Abdullah Ariff, Jonathan Meier, Gil Gonçalves, Matthieu Choplin, Ben Judson, James Gregory, Łukasz Lechowicz, Clinton Roy, Vitorino Araújo, Susan Goodbody, Josh Harwood, Daniel Butler, Liu Haibin, Jimmy Davies, Ignacio Vergara Kausel, Gaia Canestrani, Renne Rocha, pedroabi, Ashia Zawaduk, Jostein Leira, Brandon Rhodes, Jazeps Basko, simkimsia, Adrien Brunet, Sergey Nosko, et bien d’autres ; nos excuses si nous vous avons oublié sur cette liste.

Super-méga-merci à notre éditeur Corbin Collins pour ses encouragements gentils, et pour être un défenseur infatigable du lecteur. Remerciements tout aussi superlatifs au personnel de production, Katherine Tozer, Sharon Wilkey, Ellen Troutman-Zaig, et Rebecca Demarest, pour votre dévouement, professionnalisme, et attention au détail. Ce livre est incommensurablement amélioré grâce à vous.

Toutes erreurs restant dans le livre sont les nôtres, naturellement.

Qu’est-ce qui vous vient à l’esprit lorsque vous entendez le mot chaos ? Peut-être pensez-vous à une bourse bruyante, ou à votre cuisine le matin — tout est confus et en désordre. Lorsque vous pensez au mot ordre, peut-être imaginez-vous une pièce vide, sereine et calme. Pour les scientifiques, cependant, le chaos est caractérisé par l’homogénéité (uniformité), et l’ordre par la complexité (différence).

Par exemple, un jardin bien entretenu est un système hautement ordonné. Les jardiniers définissent des limites avec des chemins et des clôtures, et ils délimitent des plates-bandes ou des potagers. Au fil du temps, le jardin évolue, devenant plus riche et plus dense ; mais sans effort délibéré, le jardin deviendra sauvage. Les mauvaises herbes et les graminées étoufferont les autres plantes, recouvrant les chemins, jusqu’à ce que finalement chaque partie se ressemble à nouveau — sauvage et non gérée.

Les systèmes logiciels, eux aussi, tendent vers le chaos. Lorsque nous commençons à construire un nouveau système, nous avons de grandes idées selon lesquelles notre code sera propre et bien ordonné, mais au fil du temps, nous constatons qu’il accumule des scories et des cas particuliers et finit en un fouillis confus de classes gestionnaires et de modules utilitaires. Nous constatons que notre architecture en couches sensée s’est effondrée sur elle-même comme un diplomate trop imbibé. Les systèmes logiciels chaotiques sont caractérisés par une uniformité de fonction : des gestionnaires d’API qui ont des connaissances du domaine et envoient des emails et effectuent de la journalisation ; des classes de "logique métier" qui n’effectuent aucun calcul mais effectuent des E/S ; et tout est couplé à tout le reste de sorte que changer n’importe quelle partie du système devient périlleux. C’est si courant que les ingénieurs logiciels ont leur propre terme pour le chaos : l’anti-pattern Big Ball of Mud (Un diagramme de dépendances réel (source: "Enterprise Dependency: Big Ball of Yarn" par Alex Papadimoulis)).

Heureusement, les techniques pour éviter de créer une big ball of mud ne sont pas complexes.

L’encapsulation et l’abstraction sont des outils que nous utilisons tous instinctivement en tant que programmeurs, même si nous n’utilisons pas tous ces mots exacts. Permettez-nous de nous y attarder un instant, car ils sont un thème récurrent du livre.

Le terme encapsulation couvre deux idées étroitement liées : simplifier le comportement et cacher les données. Dans cette discussion, nous utilisons le premier sens. Nous encapsulons le comportement en identifiant une tâche qui doit être effectuée dans notre code et en confiant cette tâche à un objet ou une fonction bien défini. Nous appelons cet objet ou cette fonction une abstraction.

Jetez un œil aux deux extraits de code Python suivants :

Les deux listes de code font la même chose : elles soumettent des valeurs encodées sous forme de formulaire à une URL afin d’utiliser une API de moteur de recherche. Mais la seconde est plus simple à lire et à comprendre car elle opère à un niveau d’abstraction plus élevé.

Nous pouvons aller encore plus loin en identifiant et en nommant la tâche que nous voulons que le code effectue pour nous et en utilisant une abstraction de niveau encore plus élevé pour la rendre explicite :

Encapsuler le comportement en utilisant des abstractions est un outil puissant pour rendre le code plus expressif, plus testable et plus facile à maintenir.

La plupart des patterns de ce livre impliquent de choisir une abstraction, vous verrez donc de nombreux exemples dans chaque chapitre. De plus, Une Brève Digression : Sur le Couplage et les Abstractions discute spécifiquement de quelques heuristiques générales pour choisir des abstractions.

L’encapsulation et l’abstraction nous aident en cachant les détails et en protégeant la cohérence de nos données, mais nous devons également prêter attention aux interactions entre nos objets et fonctions. Lorsqu’une fonction, un module ou un objet en utilise un autre, nous disons que l’un dépend de l’autre. Ces dépendances forment une sorte de réseau ou de graphe.

Dans une big ball of mud, les dépendances sont hors de contrôle (comme vous l’avez vu dans Un diagramme de dépendances réel (source: "Enterprise Dependency: Big Ball of Yarn" par Alex Papadimoulis)). Modifier un nœud du graphe devient difficile car cela a le potentiel d’affecter de nombreuses autres parties du système. Les architectures en couches sont une façon de s’attaquer à ce problème. Dans une architecture en couches, nous divisons notre code en catégories ou rôles discrets, et nous introduisons des règles sur les catégories de code qui peuvent s’appeler les unes les autres.

L’un des exemples les plus courants est l'architecture à trois couches illustrée dans Architecture en couches.

L’architecture en couches est peut-être le pattern le plus courant pour construire des logiciels d’entreprise. Dans ce modèle, nous avons des composants d’interface utilisateur, qui peuvent être une page web, une API ou une ligne de commande ; ces composants d’interface utilisateur communiquent avec une couche de logique métier qui contient nos règles métier et nos flux de travail ; et enfin, nous avons une couche de base de données qui est responsable du stockage et de la récupération des données.

Pour le reste de ce livre, nous allons systématiquement retourner ce modèle en obéissant à un principe simple.

Vous connaissez peut-être déjà le principe d’inversion de dépendance (Dependency Inversion Principle, DIP), car c’est le D de SOLID.^[3]

Malheureusement, nous ne pouvons pas illustrer le DIP en utilisant trois petites listes de code comme nous l’avons fait pour l’encapsulation. Cependant, l’ensemble de la Construire une Architecture pour Supporter la Modélisation de Domaine est essentiellement un exemple détaillé d’implémentation du DIP dans une application, vous aurez donc votre dose d’exemples concrets.

En attendant, nous pouvons parler de la définition formelle du DIP :

Mais qu’est-ce que cela signifie ? Prenons-le morceau par morceau.

Les modules de haut niveau sont le code qui intéresse vraiment votre organisation. Peut-être travaillez-vous pour une société pharmaceutique, et vos modules de haut niveau traitent des patients et des essais. Peut-être travaillez-vous pour une banque, et vos modules de haut niveau gèrent des transactions et des échanges. Les modules de haut niveau d’un système logiciel sont les fonctions, classes et packages qui traitent de nos concepts du monde réel.

Par contraste, les modules de bas niveau sont le code qui n’intéresse pas votre organisation. Il est peu probable que votre département des ressources humaines soit enthousiaste à propos des systèmes de fichiers ou des sockets réseau. Ce n’est pas souvent que vous discutez de SMTP, HTTP ou AMQP avec votre équipe financière. Pour nos parties prenantes non techniques, ces concepts de bas niveau ne sont ni intéressants ni pertinents. Tout ce qui les intéresse, c’est de savoir si les concepts de haut niveau fonctionnent correctement. Si la paie fonctionne à temps, votre entreprise ne se soucie probablement pas de savoir s’il s’agit d’une tâche cron ou d’une fonction transitoire s’exécutant sur Kubernetes.

Dépend de ne signifie pas nécessairement importe ou appelle, mais plutôt une idée plus générale qu’un module connaît ou a besoin d’un autre module.

Et nous avons déjà mentionné les abstractions : ce sont des interfaces simplifiées qui encapsulent le comportement, de la façon dont notre module duckduckgo encapsulait l’API d’un moteur de recherche.

Ainsi, la première partie du DIP dit que notre code métier ne devrait pas dépendre de détails techniques ; au lieu de cela, les deux devraient utiliser des abstractions.

Pourquoi ? Globalement, parce que nous voulons pouvoir les changer indépendamment l’un de l’autre. Les modules de haut niveau devraient être faciles à changer en réponse aux besoins métier. Les modules de bas niveau (détails) sont souvent, en pratique, plus difficiles à changer : pensez au refactoring pour changer un nom de fonction versus définir, tester et déployer une migration de base de données pour changer un nom de colonne. Nous ne voulons pas que les changements de logique métier ralentissent parce qu’ils sont étroitement couplés aux détails d’infrastructure de bas niveau. Mais, de même, il est important de pouvoir changer vos détails d’infrastructure quand vous en avez besoin (pensez au sharding d’une base de données, par exemple), sans avoir besoin d’apporter des modifications à votre couche métier. Ajouter une abstraction entre eux (le fameux niveau supplémentaire d’indirection) permet aux deux de changer (plus) indépendamment l’un de l’autre.

La deuxième partie est encore plus mystérieuse. "Les abstractions ne devraient pas dépendre des détails" semble assez clair, mais "Les détails devraient dépendre des abstractions" est difficile à imaginer. Comment pouvons-nous avoir une abstraction qui ne dépend pas des détails qu’elle abstrait ? Au moment où nous arrivons au Notre Premier Cas d’Usage (Use Case) : API Flask et Couche de Service (Service Layer), nous aurons un exemple concret qui devrait rendre tout cela un peu plus clair.

Mais avant de pouvoir retourner notre architecture à trois couches, nous devons parler davantage de cette couche intermédiaire : les modules de haut niveau ou la logique métier. L’une des raisons les plus courantes pour lesquelles nos conceptions tournent mal est que la logique métier se retrouve dispersée dans les couches de notre application, ce qui rend difficile son identification, sa compréhension et sa modification.

Le Modélisation du Domaine montre comment construire une couche métier avec un pattern de Modèle de Domaine (Domain Model). Le reste des patterns de la Construire une Architecture pour Supporter la Modélisation de Domaine montre comment nous pouvons garder le Modèle de Domaine facile à changer et libre de préoccupations de bas niveau en choisissant les bonnes abstractions et en appliquant continuellement le DIP.

Comprendre le modèle de domaine prend du temps, de la patience et des Post-it. Nous avons une conversation initiale avec nos experts métier et nous nous mettons d’accord sur un glossaire et quelques règles pour la première version minimale du modèle de domaine. Dans la mesure du possible, nous demandons des exemples concrets pour illustrer chaque règle.

Nous nous assurons d’exprimer ces règles dans le jargon métier (le langage omniprésent dans la terminologie DDD). Nous choisissons des identifiants mémorables pour nos objets afin que les exemples soient plus faciles à discuter.

L’encadré suivant montre quelques notes que nous aurions pu prendre en ayant une conversation avec nos experts du domaine sur l’allocation.

Nous n’allons pas vous montrer comment fonctionne le TDD dans ce livre, mais nous voulons vous montrer comment nous construirions un modèle à partir de cette conversation métier.

Voici à quoi pourrait ressembler l’un de nos premiers tests :

Le nom de notre test unitaire décrit le comportement que nous voulons voir du système, et les noms des classes et variables que nous utilisons sont tirés du jargon métier. Nous pourrions montrer ce code à nos collègues non techniques, et ils seraient d’accord que cela décrit correctement le comportement du système.

Notre implémentation ici est triviale : un Batch enveloppe simplement un entier available_quantity, et nous décrémentons cette valeur lors de l’allocation. Nous avons écrit beaucoup de code juste pour soustraire un nombre d’un autre, mais nous pensons que modéliser notre domaine avec précision sera payant.^[6]

Écrivons quelques nouveaux tests qui échouent :

Il n’y a rien de trop inattendu ici. Nous avons refactorisé notre suite de tests pour que nous ne répétions pas les mêmes lignes de code pour créer un lot et une ligne pour le même SKU ; et nous avons écrit quatre tests simples pour une nouvelle méthode can_allocate. Encore une fois, remarquez que les noms que nous utilisons reflètent le langage de nos experts du domaine, et les exemples sur lesquels nous nous sommes mis d’accord sont directement écrits dans le code.

Nous pouvons implémenter cela de manière simple, aussi, en écrivant la méthode can_allocate de Batch :

Jusqu’à présent, nous pouvons gérer l’implémentation en incrémentant et décrémentant simplement Batch.available_quantity, mais au fur et à mesure que nous entrons dans les tests deallocate(), nous serons forcés vers une solution plus intelligente :

Dans ce test, nous affirmons que désallouer une ligne d’un lot n’a aucun effet à moins que le lot n’ait précédemment alloué la ligne. Pour que cela fonctionne, notre Batch doit comprendre quelles lignes ont été allouées. Regardons l' implémentation :

Notre modèle en UML montre le modèle en UML.

Maintenant nous progressons ! Un lot garde maintenant la trace d’un ensemble d’objets OrderLine alloués. Quand nous allouons, si nous avons assez de quantité disponible, nous ajoutons simplement à l’ensemble. Notre available_quantity est maintenant une propriété calculée : quantité achetée moins quantité allouée.

Oui, il y a beaucoup plus que nous pourrions faire. C’est un peu déconcertant que allocate() et deallocate() puissent échouer silencieusement, mais nous avons les bases.

Incidemment, utiliser un ensemble pour ._allocations nous facilite la tâche pour gérer le dernier test, parce que les éléments dans un ensemble sont uniques :

Pour le moment, c’est probablement une critique valable de dire que le modèle de domaine est trop trivial pour s’embêter avec le DDD (ou même l’orientation objet !). Dans la vraie vie, un nombre quelconque de règles métier et de cas particuliers apparaissent : les clients peuvent demander une livraison à des dates futures spécifiques, ce qui signifie que nous ne voudrons peut-être pas les allouer au lot le plus tôt. Certains SKU ne sont pas dans des lots, mais commandés sur demande directement auprès des fournisseurs, donc ils ont une logique différente. Selon l’emplacement du client, nous ne pouvons allouer qu’à un sous-ensemble d’entrepôts et de livraisons qui sont dans leur région—sauf pour certains SKU que nous sommes heureux de livrer depuis un entrepôt dans une région différente si nous sommes en rupture de stock dans la région d’origine. Et ainsi de suite. Une vraie entreprise dans le monde réel sait comment empiler la complexité plus rapidement que nous ne pouvons le montrer sur la page !

Mais en prenant ce modèle de domaine simple comme un espace réservé pour quelque chose de plus complexe, nous allons étendre notre modèle de domaine simple dans le reste du livre et le connecter au monde réel des API, des bases de données et des feuilles de calcul. Nous verrons comment s’en tenir rigoureusement à nos principes d’encapsulation et de découpage soigneux nous aidera à éviter une boule de boue.

Nous avons créé un modèle pour représenter les lots, mais ce que nous devons réellement faire est d’allouer des lignes de commande contre un ensemble spécifique de lots qui représentent tout notre stock.

Evans discute de l’idée d’opérations de Service de Domaine qui n’ont pas de place naturelle dans une entité ou un objet valeur.^[8] Une chose qui alloue une ligne de commande, étant donné un ensemble de lots, ressemble beaucoup à une fonction, et nous pouvons profiter du fait que Python est un langage multiparadigme et simplement en faire une fonction.

Voyons comment nous pourrions tester une telle fonction :

Et notre service pourrait ressembler à ceci :

Dans Modélisation du Domaine nous avons construit un simple modèle de domaine qui peut allouer des commandes à des lots de stock. Il est facile pour nous d’écrire des tests contre ce code car il n’y a aucune dépendance ou infrastructure à mettre en place. Si nous devions exécuter une base de données ou une API et créer des données de test, nos tests seraient plus difficiles à écrire et à maintenir.

Malheureusement, à un moment donné, nous devrons mettre notre petit modèle parfait entre les mains des utilisateurs et composer avec le monde réel des feuilles de calcul, des navigateurs web et des conditions de concurrence. Pour les prochains chapitres, nous allons examiner comment nous pouvons connecter notre modèle de domaine idéalisé à un état externe.

Nous nous attendons à travailler de manière agile, donc notre priorité est d’arriver à un produit minimum viable le plus rapidement possible. Dans notre cas, ce sera une API web. Dans un projet réel, vous pourriez vous lancer directement avec des tests de bout en bout et commencer à brancher un framework web, en développant de l’extérieur vers l’intérieur par les tests.

Mais nous savons que, quoi qu’il arrive, nous allons avoir besoin d’une forme de stockage persistant, et ceci est un manuel, donc nous pouvons nous permettre un peu plus de développement ascendant et commencer à réfléchir au stockage et aux bases de données.

Quand nous construirons notre premier point de terminaison API, nous savons que nous allons avoir du code qui ressemble plus ou moins à ceci.

Nous aurons besoin d’un moyen de récupérer les informations sur les lots depuis la base de données et d’instancier nos objets du modèle de domaine à partir de celles-ci, et nous aurons également besoin d’un moyen de les sauvegarder dans la base de données.

Quoi ? Oh, "gubbins" est un mot britannique pour "trucs". Vous pouvez simplement l’ignorer. C’est du pseudo-code, OK ?

Comme mentionné dans l’introduction, une architecture en couches (layered architecture) est une approche courante pour structurer un système qui a une interface utilisateur, de la logique et une base de données (voir Architecture en couches).

La structure Modèle-Vue-Template de Django est étroitement liée, tout comme le Modèle-Vue-Contrôleur (MVC). Dans tous les cas, l’objectif est de garder les couches séparées (ce qui est une bonne chose), et de faire en sorte que chaque couche ne dépende que de celle en dessous.

Mais nous voulons que notre modèle de domaine n’ait aucune dépendance quelle qu’elle soit.^[9] Nous ne voulons pas que les préoccupations d’infrastructure contaminent notre modèle de domaine et ralentissent nos tests unitaires ou notre capacité à apporter des modifications.

Au lieu de cela, comme discuté dans l’introduction, nous considérerons notre modèle comme étant à "l’intérieur", et les dépendances affluant vers lui ; c’est ce que les gens appellent parfois architecture en oignon (onion architecture) (voir Architecture en oignon).

Rappelons-nous notre modèle de domaine (voir Notre modèle) : une allocation est le concept de lier une OrderLine à un Batch. Nous stockons les allocations comme une collection sur notre objet Batch.

Voyons comment nous pourrions traduire cela en une base de données relationnelle.

Le pattern Repository (Dépôt) est une abstraction sur le stockage persistant. Il cache les détails ennuyeux de l’accès aux données en faisant semblant que toutes nos données sont en mémoire.

Si nous avions une mémoire infinie dans nos ordinateurs portables, nous n’aurions pas besoin de bases de données maladroites. Au lieu de cela, nous pourrions simplement utiliser nos objets quand nous le voulons. À quoi cela ressemblerait-il ?

Même si nos objets sont en mémoire, nous devons les mettre quelque part pour pouvoir les retrouver. Nos données en mémoire nous permettraient d’ajouter de nouveaux objets, tout comme une liste ou un ensemble. Parce que les objets sont en mémoire, nous n’avons jamais besoin d’appeler une méthode .save() ; nous récupérons simplement l’objet qui nous intéresse et le modifions en mémoire.

Voici l’un des plus grands avantages du pattern Repository :

Parce que c’est un simple enrobage autour d’un set, toutes les méthodes tiennent en une ligne.

Utiliser un faux dépôt dans les tests est vraiment facile, et nous avons une abstraction simple qui est facile à utiliser et à raisonner :

Vous verrez ce faux en action dans le prochain chapitre.

Nous ne voulons pas nous attarder trop sur la terminologie ici parce que la chose principale sur laquelle nous voulons nous concentrer est l’inversion de dépendance, et les spécificités de la technique que vous utilisez n’ont pas trop d’importance. De plus, nous sommes conscients que différentes personnes utilisent des définitions légèrement différentes.

Les ports et adaptateurs sont sortis du monde orienté objet, et la définition à laquelle nous nous accrochons est que le port est l'interface entre notre application et tout ce que nous souhaitons abstraire, et l'adaptateur est l'implémentation derrière cette interface ou abstraction.

Maintenant, Python n’a pas d’interfaces en soi, donc bien qu’il soit généralement facile d’identifier un adaptateur, définir le port peut être plus difficile. Si vous utilisez une classe de base abstraite, c’est le port. Sinon, le port est juste le duck type auquel vos adaptateurs se conforment et que votre application principale attend — les noms de fonction et de méthode utilisés, et leurs noms et types d’arguments.

Concrètement, dans ce chapitre, AbstractRepository est le port, et SqlAlchemyRepository et FakeRepository sont les adaptateurs.

En gardant à l’esprit la citation de Rich Hickey, dans chaque chapitre nous résumons les coûts et les bénéfices de chaque pattern architectural que nous introduisons. Nous voulons être clairs que nous ne disons pas que chaque application doit être construite de cette façon ; seulement parfois la complexité de l’application et du domaine vaut-elle la peine d’investir le temps et l’effort pour ajouter ces couches supplémentaires d’indirection.

Avec cela à l’esprit, Pattern Repository et ignorance de la persistance : les compromis montre certains des avantages et inconvénients du pattern Repository et de notre modèle ignorant de la persistance.

Compromis du modèle de domaine sous forme de diagramme montre la thèse de base : oui, pour les cas simples, un modèle de domaine découplé est plus de travail qu’un simple pattern ORM/ActiveRecord.^[16]

Mais plus le domaine est complexe, plus un investissement pour vous libérer des préoccupations d’infrastructure sera payant en termes de facilité à apporter des changements.

Notre exemple de code n’est pas assez complexe pour donner plus qu’un indice de ce à quoi ressemble le côté droit du graphique, mais les indices sont là. Imaginez, par exemple, si nous décidons un jour que nous voulons changer les allocations pour qu’elles vivent sur l'`OrderLine` au lieu de sur l’objet Batch : si nous utilisions Django, par exemple, nous devrions définir et réfléchir à la migration de base de données avant de pouvoir exécuter des tests. Tel quel, parce que notre modèle est juste des objets Python ordinaires, nous pouvons changer un set() en un nouvel attribut, sans avoir besoin de penser à la base de données jusqu’à plus tard.

Vous vous demanderez comment nous instancions ces dépôts, faux ou réels ? À quoi ressemblera réellement notre application Flask ? Vous le découvrirez dans le prochain épisode passionnant, le pattern Couche de Service (Service Layer).

Mais d’abord, une brève digression.

C’est bien beau tout ça, mais comment réellement écrire ces nouveaux tests, et comment changer notre implémentation pour que tout fonctionne ?

Notre objectif est d’isoler la partie intelligente de notre système, et de pouvoir la tester minutieusement sans avoir besoin de configurer un vrai système de fichiers. Nous créerons un "noyau" de code qui n’a pas de dépendances sur l’état externe et verrons ensuite comment il répond lorsque nous lui donnons des entrées du monde extérieur (ce type d’approche a été caractérisé par Gary Bernhardt comme Functional Core, Imperative Shell, ou FCIS).

Commençons par diviser le code pour séparer les parties avec état de la logique.

Et notre fonction de niveau supérieur ne contiendra presque aucune logique du tout ; c’est juste une série impérative d’étapes : rassembler les entrées, appeler notre logique, appliquer les sorties :

Le code pour construire le dictionnaire de chemins et de hachages est maintenant trivialement facile à écrire :

La fonction determine_actions() sera le noyau de notre logique métier, qui dit : "Étant donné ces deux ensembles de hachages et de noms de fichiers, que devrions-nous copier/déplacer/supprimer ?". Elle prend des structures de données simples et retourne des structures de données simples :

Nos tests agissent maintenant directement sur la fonction determine_actions() :

Parce que nous avons démêlé la logique de notre programme—​le code pour identifier les changements—​des détails de bas niveau de l’I/O, nous pouvons facilement tester le cœur de notre code.

Avec cette approche, nous sommes passés du test de notre fonction de point d’entrée principale, sync(), au test d’une fonction de niveau inférieur, determine_actions(). Vous pourriez décider que c’est bien parce que sync() est maintenant si simple. Ou vous pourriez décider de conserver quelques tests d’intégration/d’acceptation pour tester que sync(). Mais il y a une autre option, qui est de modifier la fonction sync() pour qu’elle puisse être testée en tant que test unitaire et test de bout en bout ; c’est une approche que Bob appelle test de bout en bout (edge-to-edge testing).

Nous verrons cette idée revenir encore et encore dans le livre : nous pouvons rendre nos systèmes plus faciles à tester et à maintenir en simplifiant l’interface entre notre logique métier et l’I/O désordonné. Trouver la bonne abstraction est délicat, mais voici quelques heuristiques et questions à vous poser :

La pratique rend moins imparfait ! Et maintenant retour à notre programmation régulière…​

Comme toute bonne équipe agile, nous nous précipitons pour essayer de sortir un MVP et le mettre devant les utilisateurs pour commencer à recueillir des retours. Nous avons le cœur de notre modèle de domaine et le service de domaine dont nous avons besoin pour allouer les commandes, et nous avons l’interface de dépôt pour le stockage permanent.

Branchons toutes les pièces mobiles ensemble aussi rapidement que nous le pouvons et ensuite refactorisons vers une architecture plus propre. Voici notre plan :

Personne n’est intéressé par un long débat terminologique sur ce qui compte comme un test de bout en bout (E2E) versus un test fonctionnel versus un test d’acceptation versus un test d’intégration versus un test unitaire. Différents projets ont besoin de différentes combinaisons de tests, et nous avons vu des projets parfaitement réussis qui divisent simplement les choses en "tests rapides" et "tests lents".

Pour l’instant, nous voulons écrire un ou peut-être deux tests qui vont exercer un point de terminaison API "réel" (utilisant HTTP) et parler à une vraie base de données. Appelons-les tests de bout en bout parce que c’est l’un des noms les plus explicites.

Ce qui suit montre une première version :

Tout le monde résout ces problèmes de différentes façons, mais vous allez avoir besoin d’une façon de faire tourner Flask, possiblement dans un conteneur, et de parler à une base de données Postgres. Si vous voulez voir comment nous l’avons fait, consultez Une Structure de Projet Modèle.

En implémentant les choses de la façon la plus évidente, vous pourriez obtenir quelque chose comme ceci :

Jusqu’ici, tout va bien. Pas besoin de trop de vos bêtises "d’architecte astronaute", Bob et Harry, pourriez-vous penser.

Mais attendez une minute—​il n’y a pas de commit. Nous ne sauvegardons pas réellement notre allocation dans la base de données. Maintenant nous avons besoin d’un deuxième test, soit un qui va inspecter l’état de la base de données après (pas très boîte noire), ou peut-être un qui vérifie que nous ne pouvons pas allouer une deuxième ligne si une première aurait déjà dû épuiser le lot :

Pas tout à fait aussi joli, mais cela nous forcera à ajouter le commit.

Si nous continuons comme ça, cependant, les choses vont devenir de plus en plus laides.

Supposons que nous voulons ajouter un peu de gestion d’erreurs. Que se passe-t-il si le domaine lève une erreur, pour un SKU qui est en rupture de stock ? Ou qu’en est-il d’un SKU qui n’existe même pas ? Ce n’est pas quelque chose que le domaine connaît, ni ne devrait le savoir. C’est plutôt une vérification de cohérence que nous devrions implémenter au niveau de la base de données, avant même d’invoquer le service de domaine.

Maintenant nous regardons deux tests de bout en bout supplémentaires :

Et bien sûr, nous pourrions l’implémenter dans l’app Flask aussi :

Mais notre app Flask commence à paraître un peu lourde. Et notre nombre de tests E2E commence à devenir incontrôlable, et bientôt nous finirons avec une pyramide de tests inversée (ou "modèle de cône de glace", comme Bob aime l’appeler).

Si nous regardons ce que fait notre app Flask, il y a pas mal de ce que nous pourrions appeler de l'orchestration—récupérer des choses de notre dépôt, valider notre entrée contre l’état de la base de données, gérer les erreurs, et committer dans le chemin heureux. La plupart de ces choses n’ont rien à voir avec avoir un point de terminaison d’API web (vous en auriez besoin si vous construisiez une CLI, par exemple ; voir Remplacer l’Infrastructure : Tout Faire avec des CSVs), et ce ne sont pas vraiment des choses qui doivent être testées par des tests de bout en bout.

Il est souvent logique de séparer une couche de service, parfois appelée une couche d’orchestration ou une couche de cas d’usage (use-case layer).

Vous souvenez-vous du FakeRepository que nous avons préparé dans Une Brève Digression : Sur le Couplage et les Abstractions ?

Voici où il sera utile ; il nous permet de tester notre couche de service avec de jolis tests unitaires rapides :

Cette fausse session n’est qu’une solution temporaire. Nous nous en débarrasserons et rendrons les choses encore plus agréables bientôt, dans Motif Unité de Travail (Unit of Work Pattern). Mais en attendant le faux .commit() nous permet de migrer un troisième test depuis la couche E2E :

Certains d’entre vous se grattent probablement la tête à ce stade en essayant de comprendre exactement quelle est la différence entre un service de domaine et une couche de service.

Nous sommes désolés—nous n’avons pas choisi les noms, sinon nous aurions des façons beaucoup plus cool et amicales de parler de ces trucs.

Nous utilisons deux choses appelées un service dans ce chapitre. La première est un service d’application (notre couche de service). Son travail est de gérer les requêtes du monde extérieur et d'orchestrer une opération. Ce que nous voulons dire est que la couche de service pilote l’application en suivant un ensemble d’étapes simples :

C’est le genre de travail ennuyeux qui doit se produire pour chaque opération dans votre système, et le garder séparé de la logique métier aide à garder les choses ordonnées.

Le deuxième type de service est un service de domaine. C’est le nom pour une pièce de logique qui appartient au modèle de domaine mais ne se trouve pas naturellement dans une entité ou un objet de valeur avec état. Par exemple, si vous construisiez une application de panier d’achat, vous pourriez choisir de construire les règles de taxation comme un service de domaine. Calculer les taxes est un travail séparé de la mise à jour du panier, et c’est une partie importante du modèle, mais cela ne semble pas correct d’avoir une entité persistée pour le travail. Au lieu de cela, une classe TaxCalculator sans état ou une fonction calculate_tax peut faire le travail.

À mesure que notre application grandit, nous aurons besoin de continuer à ranger notre structure de répertoires. La disposition de notre projet nous donne des indices utiles sur quels types d' objets nous trouverons dans chaque fichier.

Voici une façon dont nous pourrions organiser les choses :

Qu’en est-il des ports ? Comme vous vous en souvenez peut-être, ce sont les interfaces abstraites que les adaptateurs implémentent. Nous avons tendance à les garder dans le même fichier que les adaptateurs qui les implémentent.

Ajouter la couche de service nous a vraiment apporté pas mal de choses :

Voyons ce que ce passage à l’utilisation d’une couche de service, avec ses propres tests de couche de service, fait à notre pyramide de tests :

Pas mal ! Nous avons 15 tests unitaires, 8 tests d’intégration, et juste 2 tests de bout en bout. C’est déjà une pyramide de tests à l’allure saine.

Voyons ce qui se passe si nous poussons cela un peu plus loin. Puisque nous pouvons tester notre logiciel contre la couche de service, nous n’avons pas vraiment besoin de tests pour le modèle de domaine plus. Au lieu de cela, nous pourrions réécrire tous les tests de niveau domaine de Modélisation du Domaine en termes de la couche de service :