Remarque: Si vous pensez qu'au moins la moitié d'un chien a été mangé lors de la construction de l'architecture, cet article n'est pas pour vous.
Un modèle est une représentation abstraite de la réalité sous une forme ou une autre.
Nous supposons que l'architecte a déjà terminé la collecte des exigences pour le futur système et leur analyse.
Le développement de l'architecture ne doit commencer qu'avec le concept et l'adoption du concept fondamental de travailler avec des informations (données): transmission, stockage et traitement. De plus, les formes d'entrée / sortie d'informations, les schémas de traitement, les structures abstraites de tableaux et les éléments de données eux-mêmes sont également des informations (comme l'ensemble de l'application) et obéissent au même concept fondamental.
Le concept fondamental conduit aux premières idées et à la création des premiers modèles informatiques.
Les modèles de travail avec des données peuvent être appelés différemment en raison de la différence de concepts imbriqués. L'un des noms est flux de données, où les éléments sont généralement de futurs modules élargis qui implémentent des tâches de manipulation de données spécifiques.
La base de l'architecture (le modèle principal) sera le modèle du processus métier de déplacement des données principales (à quoi l'application sera destinée). Cette étape est très dangereuse: beaucoup d'idées originales peuvent inonder l'architecte. Ce flux d'idées doit être contenu. Supprimez le désir de rêver ou de dessiner un tas de schémas inutiles. Vous devez maintenant créer un seul schéma pour obtenir séquentiellement les données de base, le stockage et le traitement. Rien de plus. Aucune décomposition n'est nécessaire ici. C'est un tel schéma qui sous-tend, est la principale représentation de l'architecture et devrait toujours être en vue. En tant que processus métier, il peut s'agir d'une carte technologique.
Le deuxième modèle principal consistera à ajouter des processus commerciaux et des données secondaires. Par exemple, les modèles utilisateur, le contrôle d'accès (ACL), les modèles de journalisation, les modèles de surveillance, les modèles d'événement, etc. sont ajoutés. Sur la base du deuxième modèle, il est déjà possible de développer le premier schéma de base de données et / ou entrepôt de données, et une application prototype. À ce stade, la compréhension peut se faire sur l'opportunité de faire une application monolithique, un composant, d'appliquer une approche de microservice ou une autre. Le fait est intéressant: entre le monolithe et chaque microservice (dans l'architecture des microservices) il n'y a pas de différences du point de vue du concept fondamental. A partir de ce moment, il est nécessaire de commencer le développement d'un document de justification de l'architecture. Un document de justification de l'architecture est un enregistreur de raisonnement sur les raisons des décisions prises par l'architecture et les explications.
La création du premier prototype d'application basé sur le deuxième modèle peut montrer l'avantage immédiat de l'application. Le prototype sera certainement une mise en page d'application formalisée. Par exemple, au lieu de formulaires détaillés, vous pouvez utiliser des boutons conditionnels qui créent un élément prêt à l'emploi basé sur des générateurs de données aléatoires.
Après avoir créé le deuxième modèle principal et le premier prototype, vous pouvez commencer la décomposition, l'agrandissement, le développement d'autres représentations et modèles architecturaux. Mais le premier modèle principal et le deuxième modèle principal seront de base. En cours de développement, les premier et deuxième modèles peuvent être améliorés, raffinés et raffinés.