Architecture d'application ou comment gâcher le karma sur Habré

Vous pouvez parler beaucoup de l'architecture des applications, des principes SOLID, OOP, des modèles architecturaux comme les couches ou l'oignon, etc. modèles de conception. Tout au long de mon expérience, j'ai réalisé une chose: combien de personnes ont autant d'opinions. Quand on est programmeur débutant, on a beaucoup d'ambitions, on grandit un peu en qualification, on a l'impression de tout savoir, et tout ce qu'on vous a fait est "mauvais", et vous ferez certainement mieux ... Mais les années passent et l'expérience acquise suggère le contraire. Sous la coupe, je vais essayer de vous parler brièvement et surtout, en termes simples, de la qualité de l'architecture. Au moins extensible et supporté, pour plus de détails, je demande un chat…

Tout d'abord, pour créer une bonne architecture du projet, vous devez décider de ses caractéristiques:

1. L'architecture doit être prise en charge.
2. Extensibilité du système sans béquilles.
3. Flexibilité des paramètres, de nombreuses tâches doivent être résolues sans changer le code du programme.
4. Fiabilité de l'architecture.

Le premier point est que la facilité de prise en charge est résolue en suivant les principes de SOLID, fondamentalement, bien sûr, le principe de "l'unicité de la responsabilité", vous devez donc choisir une architecture basée sur des microservices ou une architecture modulaire d'un système central monolithique. Il n'y a pas de différence fondamentale entre ces approches. Pour le projet sur lequel je travaille, j'ai choisi la 2ème approche, les modules.

Le deuxième point peut être résolu en utilisant le modèle de programmation de l'observateur d'événements ou du répartiteur. Ils sont similaires les uns aux autres, nous ne nous concentrerons donc pas là-dessus. L'essence de leur travail est de jeter un message du module en cours d'exécution et, si nécessaire, d'écouter le module qui doit travailler avec cet objet.

Le troisième paragraphe est également résolu tout simplement, la partie descriptive de l'entité, c'est-à-dire les attributs des entités stockés séparément de l'entité elle-même. Il s'agit d'une référence à EAV (Entity Attribute Value). Vous n'avez pas à traiter tous les champs d'une entité pour la logique métier, certains attributs portent une charge informative, d'autres sont utilisés pour le tri et le filtrage, et seulement une partie pour la construction de la logique métier. Par conséquent, si l'entité est stockée en EAV, nous pouvons à tout moment ajouter ou supprimer un attribut dont nous n'avons pas besoin.

Le quatrième point de nos exigences est la fiabilité, ce qui signifie un minimum de «béquilles» et plus d'automatisation. La plupart des applications Web se composent d'interfaces d'affichage de données, de tableaux, de filtres, de tri, de cartes d'entité. Et interfaces de saisie de données, formulaires. Par conséquent, il vaut la peine d'utiliser des usines pour les formulaires, des usines pour les tables, des usines pour les cartes. Plus d'automatisation, au final on peut faire abstraction du domaine de la présentation, et se concentrer sur la logique métier et les tâches de fond ...

Et donc la conclusion se suggère que pour construire une bonne architecture, il est nécessaire d'abstraire, de décider des technologies et des modèles de programmation et de construire une base pour commencer le développement ...

Nous avons maintenant développé un plan, décidé des exigences, puis nous devons décider comment construire l'architecture. En fait, je ne comprends pas toutes ces architectures ou oignons en couches. J'ai pris quelque chose d'eux et j'ai inventé quelque chose moi-même, et je n'y vois rien si les gens comprennent ce que cela signifie. En fait, toute l'architecture se résume à des étapes simples:

• Le fondement est l'abstraction (classes abstraites et interfaces qui définissent le contrat de divers composants du système combinés en modules)
• Ensuite, j'ai une couche noyau qui exécute les modules et les gère.
• Chargement du système de mise en page
• Après le démarrage du module, chaque module en tant que microservice distinct

Mais qu'est-ce qui fait que l'architecture est bonne? La question n'est pas simple, mais si tout est simplifié au niveau du raisonnement philosophique, alors cette question recevra une réponse. Après le démarrage de l'application. Nous avons des pièces isolées, des modules. Chaque module est responsable d'une seule fonctionnalité du système. Nous descendons chaque module, conçu comme une application mvc et avons une vue, un contrôleur, un modèle. Et chaque partie du module est également responsable de chacune de ses actions. Nous descendons encore plus profondément et nous verrons que la vue a également certaines parties, ce sont des classes d'usine et des extensions de mise en page. En fait, les layouts sont aussi un module, il est tout d'abord chargé, tous les autres modules le complètent, et construisent une interface (ou système de sortie). Mais comment faites-vous pour rendre tout cela moins dépendant? Et la réponse sera évidente pour les observateurs, pour chaque rendu du bloc de mise en page qu'ils lancent leurs événements, il vous suffit d'écouter cet événement, d'observer dans votre application, d'ajouter la mise à jour de bloc nécessaire dans les couches et d'obtenir la sortie appropriée. De nombreux modules ont également leurs propres événements, auxquels d'autres modules s'abonnent et sont capables d'ajouter / ou de mettre à jour des données dans l'ensemble transféré. Tout cela conduit au fait que dans l'application, les modules sont peu connectés entre eux et peuvent vivre les uns sans les autres.

À la lumière de ce qui précède, une question raisonnable se pose: si un module écoute un autre, alors il est nécessaire d'avoir une sorte de système de gestion des dépendances pour ces modules. Autrement dit, le module dont dépend un autre module, nous devons commencer en premier, et celui qui dépend, nous devons exécuter après. Et donc une implémentation simple de la dépendance est née, nous créons une file d'attente pour le lancement des modules et la trions simplement de telle manière que les modules dont dépendent les autres soient chargés d'abord, après le chargement du noyau, bien sûr.

En conclusion, je peux dire ce qui suit. Une bonne architecture n'est pas une tâche si difficile et à long terme pour y économiser. Et au final, cela aide à dépenser les ressources et le temps plus efficacement. Après tout, changer le réglage dans le panneau de commande est une affaire de cinq minutes. Ecrire deux lignes à ajouter n'est pas non plus si long. Mais tirer une conclusion, inverser tout le monde, déboguer de grandes quantités de données est déjà un temps beaucoup plus long que le temps de développer une stratégie de construction d'architecture.