Architecture propre : par où commencer ?

Dans le post précédent nous avons :

• Notre domaine problématique : une application ToDo avec quelques exigences
• Un référentiel de base configuré pour utiliser Python et Python Polylith.

Certaines décisions sont donc prises en compte. Nous disposons de certains outils et avons décidé à quoi ressemblera le référentiel.

C'est l'une des choses que j'aime chez Polylith : peu importe ce que vous codez ou la taille de votre organisation, tous les référentiels se ressembleront - si vous en avez besoin de plusieurs.

La structure de votre référentiel est cohérente, que vous utilisiez FastAPI, Flask ou Django, que vous construisiez une ou plusieurs bibliothèques ou que vous exécutiez des tâches en arrière-plan avec Celery.

L'un des principaux avantages est le processus d'intégration simplifié pour les nouveaux développeurs. En supposant qu'ils maîtrisent Polylith, ils se familiariseront rapidement avec la structure du projet : les composants réutilisables sont dans le dossier des composants, les points d'entrée sont dans le dossier bases, les scripts de démonstration sont dans le dossier de développement, etc.

Entités

De l'oncle Bob "L'architecture propre" Les entités sont la pierre angulaire de notre architecture, elles constituent la couche la plus interne de notre architecture. Nous devons donc commencer par eux, dans Polylith, les entités devraient vivre comme des composants.

Combien de composants ?

Je pense que le nombre de composants dépend de la taille et de la complexité de votre solution. Cependant, je recommande de commencer avec un composant polylithique unique pour les entités. Cette approche permet de maintenir une architecture claire et ciblée, en particulier pour les petits projets.

Pourquoi un composant unique pour les entités ?

• Cette couche encapsule les règles métier de base qui sont fondamentales pour l'ensemble de l'application. En le gardant dans un seul composant, vous assurez la cohérence et évitez les duplications.
• Un seul composant simplifie la gestion des dépendances, car il devient une dépendance pour toutes les autres couches.

Évitez les dépendances tierces.

Pour minimiser les dépendances externes et améliorer la flexibilité architecturale, efforcez-vous d'utiliser la bibliothèque standard de Python pour représenter les entités. Cela inclut l'exploitation des structures de données telles que dict, list, enum, fonctions, classes et plus récemment dataclasses.

Pourquoi éviter les bibliothèques tierces comme Pydantic ou Django Models ?

• Couplage à des frameworks externes : s'appuyer sur ces bibliothèques peut introduire un couplage inutile à des frameworks spécifiques.
• Complexité accrue : les bibliothèques externes peuvent ajouter de la complexité et des problèmes de maintenance potentiels.
• Flexibilité réduite : En limitant les dépendances externes, vous pouvez vous adapter plus facilement aux changements d'exigences ou de technologie.

En adhérant à ces principes, vous pouvez créer une architecture robuste et maintenable qui résiste aux changements futurs.

Entités ToDo

Notre exemple est simple, l'entité principale étant la « tâche à faire » pour Gordon. Nous pouvons ajouter un nouveau composant à notre référentiel, mais choisir le bon nom est crucial.

Bien qu'il puisse être tentant d'utiliser des noms génériques comme « core » ou « main », il est essentiel de sélectionner des noms significatifs dans le contexte du domaine. Idéalement, ces noms doivent correspondre à la terminologie utilisée par le client ou le propriétaire du produit. En utilisant des noms spécifiques au domaine, nous améliorons la lisibilité et la maintenabilité du code, permettant ainsi aux développeurs et aux parties prenantes de comprendre plus facilement la structure du projet.

Le nom de l'espace de travail du référentiel est défini comme todo. Par conséquent, toutes nos importations suivront le format :

from todo.XYZ import ...
import todo.XYZ

Pour simplifier, dans cet exemple, nous utiliserons des entités comme nom de composant. Cependant, dans des scénarios réels, envisagez des conventions de dénomination qui reflètent votre domaine. Par exemple, si votre application tourne autour de la récupération de documents, un composant nommé récupération serait approprié. De même, une application de jeu peut utiliser Tournaments_entities pour plus de clarté.

Créer le composant avec Python Polylith est simple :

poetry poly create component --name=entities
poetry poly sync
poetry install # it may be necessary

Cela ajoutera un package python dans le dossier des composants, voici les nouvelles entrées dans l'arborescence des sources :

./components
└── todo
    └── entities
        ├── __init__.py
        └── core.py
./test/components
└── todo
    └── entities
        ├── __init__.py
        └── test_core.py

L'outil python-polylith générera des exemples de tests pour nous, ce qui est une fonctionnalité intéressante. Ce comportement peut être modifié dans le fichier workspace.toml en définissant la valeur activé = true sur false dans la section [tool.polylith.test].

Dans le nouveau composant entités, deux fichiers sont ajoutés : __init__.py et core.py. Vous pouvez renommer le module core.py pour mieux répondre à vos besoins. La pratique courante consiste à exposer l'API publique du package via __init__.py, tout en conservant l'organisation interne au sein d'autres modules comme core.py.

Parmi les exigences, nous n'avons, pour le moment, qu'une seule entité, l'élément ToDo :

@dataclass
class TodoItem:
    owner: str
    title: str
    description: str
    is_done: bool = False
    due_date: Optional[date] = None

Tester une entité aussi simple peut sembler inutile, mais je préfère tester au moins la présence de tous les champs. Bien que cela ne semble pas crucial dans les petits projets avec moins de contributeurs, cela peut éviter des problèmes importants dans les projets plus importants avec de nombreux développeurs. La suppression d'un seul champ de l'entité peut interrompre par inadvertance diverses parties de l'application.

Dans la pull request de cette partie, vous verrez que j'ai ajouté quelques tests de base pour cette entité.

Avec certains tests déjà définis, j'en ai profité pour ajouter un workflow GitHub pour exécuter automatiquement les tests à chaque pull request.

Conclusions

• Entités de base de l'application
• Configuration CI

Et ensuite : parlons de persévérance

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!