Andrey Kopylov , notre directeur technique, nous explique quelle approche l'équipe de développement web AREALIDEA utilise pour concevoir l'architecture des applications, et ce qu'est KISS Architecture, son propre développement, est si bon.
Il existe de nombreuses approches pour concevoir une architecture d'application. MVC, DDD, Clean Architecture et bien d'autres.
MVC est bien adapté aux petites applications. Lorsque vous essayez de vous adapter, MVC devient l'architecture la plus courante dans le monde informatique - Big Lump of Dirt .
DDD est une excellente architecture, mais personne ne la comprend. A moins que le créateur lui-même et quelques architectes. Le but de l'architecture est de la rendre compréhensible pour chaque développeur.
L'architecture propre est une excellente architecture, mais sa mise en œuvre complète a du sens pour les applications énormes. Pour les petites et moyennes, cela m'a paru trop compliqué.
Les tendances actuelles - la transition vers les services et les microservices - dans ce contexte, l'architecture propre devient trop lourde.
Il semblerait alors, prenons MVC pour microservice et arrêtons-nous là-dessus. Mais non, un tel vélo ne nous convient pas.
Composants
Le vélo pour les projets de notre agence est assemblé à partir de pièces détachées issues de différentes approches architecturales.
Voici les composants dont vous avez besoin pour créer une structure compréhensible et pratique:
- Routeurs
- Contrôleurs
- Vues
- Les services
- Les modèles
Couches
Routeur
Le routeur est responsable du routage des demandes. La taille du routeur et leur nombre indiquent indirectement la taille de votre application. Pour une grande application monolithique, il peut y avoir plus d'une couche de routeurs.
Le routeur est présent dans n'importe quelle architecture, mais souvent implicitement. Et comme l'évidence vaut mieux que l'implicite, cela vaut la peine de le retirer - pour en faire une partie intégrante de l'architecture.
Contrôleur
Le contrôleur est une couche entre le routeur et les services. Il ne doit pas y avoir de logique métier dans le contrôleur.
Chaque contrôleur ne contrôle qu'une seule entité. Si vous avez besoin de plus d'entités, vous devez ajouter un autre contrôleur.
Le nombre et la taille des contrôleurs indiquent indirectement la taille de votre application. La couche verticale sous le contrôleur peut être séparée dans un microservice distinct.
Vues
La vue est dans une couche avec le contrôleur, est responsable de l'affichage final des données. Le contrôleur après réception des données du service transfère les données à la vue et renvoie la vue pour affichage.
Dans le cas extrême, View est JSON, XML et des formats similaires.
Les services
Seul un service peut contenir une logique métier. Un service fait généralement référence à un seul modèle. Un service peut appeler un autre service.
La couche de service est divisée en commandes et requêtes (commandes et requêtes). Il s'agit de l'approche standard pour le CQRS .
Un service ne remplit qu'une seule fonction. Il peut y avoir un certain nombre de fonctions privées et un seul public. Le nom du service commence par un verbe. Exemples: GetUsers, GetPostById, UpdateUser, PublishPost. C'est le nom du service qui indique la séparation correcte des fonctionnalités.
Dans les requêtes, nous mettons des services qui ne modifient pas la base de données. La requête contient une fonction get publique. Dans les commandes, nous mettons des services qui modifient la base de données. La commande contient une fonction d' exécution publique.
Les modèles
Le modèle contient uniquement la logique la plus simple associée à la lecture et à l'enregistrement des données. De plus, ces manipulations peuvent ne pas être liées à la base de données.
Si le modèle fonctionne avec une base de données, un modèle ne sert qu'une ou plusieurs tables.
Recettes
Microservice
À ma connaissance, un microservice ne devrait gérer qu'une seule entité. Par conséquent, l'architecture du microservice le plus simple ressemblera à ceci:
- un routeur;
- un contrôleur;
- plusieurs vues;
- plusieurs services;
- un modèle.
Le service
Le service est une mini application. Il contient:
- un routeur;
- plusieurs contrôleurs;
- plusieurs vues;
- plusieurs services;
- Plusieurs modèles.
Monolith
Monolith est une excellente application. Personne n'aime les monolithes à cause de leur monstruosité. Un monolithe est justifié si vous suivez la première approche Monolith. Dans cet état, votre application peut rester pendant un certain temps.
Le monolithe contient:
- un SuperRouter;
- plusieurs routeurs ordinaires;
- de nombreux contrôleurs;
- de nombreuses vues, de nombreux services;
- de nombreux modèles.
Cela commence à paraître un peu effrayant. Ici, vous pouvez clairement voir la séparation verticale supplémentaire des couches. Cela permet à l'application de rester gérée et maintenue. Le sciage d'un monolithe en pièces devient une tâche purement mécanique.
Pour préserver l'harmonie de l'architecture dont vous avez besoin:
- Ajoutez un routeur de niveau supérieur qui résoudra les chemins globaux - SuperRouter.
- Répartissez les fichiers dans une structure par module. Autrement dit, conformément à la future coupe des services individuels.
Test
Dans le cadre de l'architecture considérée, seuls les services sont soumis à des tests rigoureux - seule la logique métier y est intégrée. Et il vous suffit d'obtenir des modèles humides.
Si vous avez envie de tester autre chose que des services, alors la place de la logique est probablement mal choisie.
Conclusion
À mon avis, KISS Architecture convient à 80% des projets et permet une évolution en douceur du projet.
Cette approche architecturale sera claire pour tous les développeurs et pour son application dans la pratique, vous n'avez pas besoin de lire des livres épais sur DDD.