book

Modèles d'architecture avec Python

by Harry Percival, Bob Gregory

November 2024

Intermediate to advanced

304 pages

8h 13m

French

O'Reilly Media, Inc.

Book available

Read now

Unlock full access

Gérer la complexité, résoudre les problèmes de l'entreprisePourquoi Python ?TDD, DDD et architecture pilotée par les événementsQui devrait lire ce livre ?Un bref aperçu de ce que tu apprendrasPartie I, Construire une architecture pour soutenir la modélisation du domainePartie II, Architecture pilotée par les événementsContenu supplémentaireExemple de code et de codageLicenceConventions utilisées dans ce livreApprentissage en ligne O'ReillyComment contacter O'ReillyRemerciements
Pourquoi nos conceptions vont-elles à vau-l'eau ?Encapsulation et abstractionsSuperpositionLe principe d'inversion de la dépendanceUn endroit pour toute notre logique d'entreprise : Le modèle de domaine
Qu'est-ce qu'un modèle de domaine ?Explorer le langage du domaineTest unitaire des modèles de domaineLes classes de données sont idéales pour les objets de valeurObjets et entités de valeurTout ne doit pas être un objet : Une fonction de service de domaineLes méthodes magiques de Python nous permettent d'utiliser nos modèles avec Python idiomatique.Les exceptions peuvent aussi exprimer des concepts de domaine
Persistance de notre modèle de domaineUn peu de pseudo-code : De quoi allons-nous avoir besoin ?Application du DIP à l'accès aux donnéesRappel : Notre modèleLa méthode ORM "normale" : Le modèle dépend de l'ORMInverser la dépendance : L'ORM dépend du modèlePrésentation du modèle de référentielLe référentiel dans le résuméQuel est le compromis ?Construire un faux dépôt pour les tests est maintenant trivial !Qu'est-ce qu'un port et qu'est-ce qu'un adaptateur, en Python ?Récapitulation
L'abstraction de l'état favorise la testabilitéChoisir les bonnes abstractionsMise en œuvre des abstractions que nous avons choisiesTester d'un bord à l'autre avec des imitations et l'injection de dépendancePourquoi ne pas simplement faire un rafistolage ?Récapitulation
Relier notre application au monde réelUn premier test de bout en boutLa mise en œuvre simpleConditions d'erreur nécessitant une vérification de la base de donnéesIntroduction d'une couche de service et utilisation de FakeRepository pour la tester à l'unitéUne fonction de service typiquePourquoi tout s'appelle-t-il un service ?Range tes affaires dans des dossiers pour savoir où elles se trouventRécapitulationLe DIP en action
Comment se présente notre pyramide de test ?Les tests de la couche domaine doivent-ils être transférés à la couche service ?Décider du type de test à écrireGrande et petite vitesseDécoupler complètement les tests de la couche service du domaineAtténuation : Conserver toutes les dépendances de domaine dans les fonctions de fixationAjouter un service manquantPoursuivre l'amélioration jusqu'aux tests E2ERécapitulation
L'unité de travail collabore avec le référentielTests d'intégration d'un outil de travail non conventionnelUnité de travail et son contexte ManagerLa véritable unité de travail utilise les sessions SQLAlchemyFausse unité de travail pour les testsUtilisation de l'UoW dans la couche de serviceTests explicites pour le comportement Commit/RollbackEngagements explicites ou implicitesExemples : Utilisation de l'UoW pour regrouper plusieurs opérations dans une unité atomiqueExemple 1 : RéaffecterExemple 2 : Modification de la quantité de lotsTiens en ordre les tests d'intégrationRécapitulation
Pourquoi ne pas tout gérer dans une feuille de calcul ?Invariants, contraintes et cohérenceInvariants, Concurrence et VerrousQu'est-ce qu'un agrégat ?Choisir un agrégatUn agrégat = un référentielQu'en est-il de la performance ?Concurrence optimiste avec numéros de versionOptions de mise en œuvre pour les numéros de versionTest de nos règles d'intégrité des donnéesRenforcer les règles de concordance en utilisant les niveaux d'isolation des transactions de la base de donnéesExemple de contrôle de la concurence pessimiste : SÉLECTIONNER POUR METTRE À JOURRécapitulationRécapitulation de la première partie

Éviter le désordreTout d'abord, évitons de mettre le bazar dans nos contrôleurs Web.Et ne faisons pas non plus de notre modèle un gâchisOu la couche de service !Principe de responsabilité uniqueTous à bord du bus à messages !Le modèle enregistre les événementsLes événements sont de simples classes de donnéesLe modèle soulève des événementsLe bus de messages associe les événements aux gestionnairesOption 1 : La couche de service prend les événements du modèle et les place sur le bus de messages.Option 2 : La couche de service déclenche ses propres événementsOption 3 : L'UoW publie des événements sur le bus de messagesRécapitulation
Une nouvelle exigence nous conduit à une nouvelle architectureImaginer un changement d'architecture : Tout sera un gestionnaire d'événementsTransformer les fonctions de service en gestionnaires de messagesLe bus de messages recueille maintenant les événements de l'UoWNos tests sont tous écrits en termes d'événements aussiUne mauvaise manipulation temporaire : le bus à messages doit renvoyer les résultatsModifier notre API pour qu'elle fonctionne avec des événementsMise en œuvre de notre nouvelle exigenceNotre nouvel événementTest d'un nouveau gestionnaireMise en œuvreUne nouvelle méthode sur le modèle du domaineOptionnellement : Test unitaire des gestionnaires d'événements en isolation avec un faux bus de messagesRécapitulationQu'avons-nous accompli ?Pourquoi avons-nous réussi ?
Commandes et événementsDifférences dans le traitement des exceptionsDiscussion : Événements, commandes et gestion des erreursRécupération des erreurs de manière synchroneRécapitulation
Boule de boue distribuée, et penser en termes de nomsTraitement des erreurs dans les systèmes distribuésL'alternative : Découplage temporel à l'aide de la messagerie asynchroneUtilisation d'un canal Pub/Sub de Redis pour l'intégrationTout tester en utilisant un test de bout en boutRedis est un autre adaptateur mince autour de notre bus de messages.Notre nouvel événement sortantÉvénements internes ou externesRécapitulation
Les modèles de domaine sont à écrireLa plupart des utilisateurs ne vont pas acheter tes meubles.Post/Redirect/Get et CQSAccrochez-vous à votre déjeuner, les amisTest des vues CQRSAlternative "évidente" 1 : utiliser le référentiel existantTon modèle de domaine n'est pas optimisé pour les opérations de lectureAlternative "évidente" 2 : Utiliser l'ORMSELECT N+1 et autres considérations de performanceIl est temps de sauter complètement le requinMise à jour d'une table de modèle de lecture à l'aide d'un gestionnaire d'événementsChanger la mise en œuvre de notre modèle de lecture est facileRécapitulation
Dépendances implicites ou explicitesLes dépendances explicites ne sont-elles pas totalement bizarres et Java ?Préparer les manipulateurs : DI manuel avec fermetures et partielsUne alternative à l'utilisation des classesUn script BootstrapLe bus de messages reçoit des gestionnaires au moment de l'exécutionUtiliser Bootstrap dans nos points d'entréeInitialiser DI dans nos testsConstruire un adaptateur "correctement" : Un exemple concretDéfinir les implémentations abstraites et concrètesFais une fausse version pour tes testsTrouve comment tester l'intégration de l'objet réelRécapitulation
Et maintenant ?Comment y arriver à partir d'ici ?Séparer les responsabilités enchevêtréesIdentifier les agrégats et les contextes limitésUne approche pilotée par les événements pour aller vers les microservices via le modèle Strangler.Convaincre tes partenaires d'essayer quelque chose de nouveauQuestions posées par nos évaluateurs techniques que nous n'avons pas pu traduire en parolesPistolets à piedPlus de lectures obligatoiresRécapitulation
Env Vars, 12-Factor, et Config, conteneurs intérieurs et extérieursConfig.pyDocker-Compose et la configuration des conteneurs.Installer ta source en tant que paquetFichier DockerTestsRécapitulation
Mise en place d'un référentiel et d'une unité de travail pour les CSV
Modèle de dépôt avec DjangoMéthodes personnalisées sur les classes ORM de Django pour traduire de/vers notre modèle de domaineModèle d'unité de travail avec DjangoAPI : Les vues de Django sont des adaptateursPourquoi tout cela était-il si difficile ?Que faire si tu as déjà DjangoLes étapes du chemin
Qu'est-ce que la validation ?Validation de la syntaxeLa loi de Postel et le modèle du lecteur tolérantValider à la périphérieValidation de la sémantiqueValider la pragmatique

Content preview from Modèles d'architecture avec Python

Annexe A. Diagramme et tableau récapitulatifs

Voici à quoi ressemble notre architecture à la fin du livre :

diagram showing all components: flask+eventconsumer, service layer, adapters, domain etc

Le tableau A-1 récapitule chaque modèle et ce qu'il fait.

Tableau A-1. Les composants de notre architecture et ce qu'ils font tous
Couche	Composant	Description
Domaine Définit la logique commerciale.	Entité	Un objet du domaine dont les attributs peuvent changer mais qui a une identité reconnaissable dans le temps.
	Objet de valeur	Un objet de domaine immuable dont les attributs le définissent entièrement. Il est fongible avec d'autres objets identiques.
	Agrégat	Groupe d'objets associés que nous traitons comme une unité dans le cadre des modifications de données. Définit et applique une limite de cohérence.
	Événement	Représente quelque chose qui s'est produit.
	Commande	Représente une tâche que le système doit effectuer.
Couche de service Définit les tâches que le système doit effectuer et orchestre les différents composants.	Manipulateur	Reçoit une commande ou un événement et exécute ce qui doit se passer.
	Unité de travail	Abstraction autour de l'intégrité des données. Chaque unité de travail représente une mise à jour atomique. Rend les référentiels disponibles. Suit les nouveaux événements sur les agrégats récupérés.
	Bus de messages (interne)	Gère les commandes et les événements en les acheminant vers le gestionnaire approprié.
Adaptateurs (secondaires) ...