[JAVA] Éléments à prendre en compte lors du choix de l'architecture d'un nouveau système

En premier

Je m'appelle @kazuis et je suis ingénieur chez LITALICO Co., Ltd. Je suis principalement en charge du système d'entreprise de services sociaux pour personnes handicapées fourni par LITALICO.

Cet article est l'article du 13ème jour de "LITALICO Advent Calendar 2017".

Lors de la création d'un nouveau système, vous vous demandez peut-être quelle langue, quel moyen et quelle méthode utiliser. Il y a peu de sens d'un résumé sympa du processus de détermination de l'architecture d'un système. Même en cascade, il existe de nombreuses méthodes telles que le scram et les livres de conception. Et les informations linguistiques et middleware débordent sur Internet.

Cependant, il semble y avoir peu d'informations sur les points clés pour la sélection de l'architecture pendant cette période.

Je vais le résumer brièvement avec le sens d'organiser mes pensées.

L'architecture appropriée doit être différente pour chaque organisation et projet. Je voudrais écrire sur l'approche pour trouver le «juste» pour chaque personne et chaque entreprise.

C'est difficile à écrire si vous choisissez une large gamme avec l'architecture du système Cette fois, je n'écrirai que les éléments liés au langage et au framework.

Informations que vous souhaitez collecter au moment de décider

L'architecture d'un système dépend grandement de «pourquoi vous avez besoin d'un système». Pour le dire un peu exagérément, est-ce un système bancaire ou un mini-jeu pour un site événementiel? Ils ne doivent pas nécessairement être de la même architecture.

Tout d'abord, vous devez savoir pourquoi vous souhaitez créer un système.

En les collectant, vous comprendrez les exigences du système. Et vous devez savoir quoi faire.

Il est également important d'avoir le même flux commercial et les mêmes exigences fonctionnelles. Le plus important est de connaître le "concept que vous voulez chérir".

Si le domaine principal n'a pas l'architecture appropriée Je ne sais pas à quoi sert le système. Je pense qu'il est souvent clairement défini comme un système pour les utilisateurs, mais je pense qu'il y a peu de systèmes d'entreprise.

Après cela, vous aurez besoin des informations que vous avez normalement analysées les exigences. Si la raison de la construction d'un nouveau système est systématique, avant les exigences du système Dans une certaine mesure, je souhaite changer la langue ou changer l'infrastructure de l'infrastructure vers le cloud Je pense que c'est souvent l'objectif de changer l'architecture.

En outre, en premier lieu, le flux commercial est trop rapide pour procéder au développement du système après avoir pris une décision. Cela peut être une période difficile. Ici, je pense qu'il suffit de pouvoir déterminer s'il faut procéder en fonction des besoins ou prioriser les retours.

Exemples de raisons commerciales

Je veux une fonction pour développer de nouveaux canaux de vente et de nouveaux produits. Pour le moment, je veux un système parce que je veux faire du XXX (vitesse) Je souhaite améliorer considérablement l'efficacité du travail.

Exemples de raisons systématiques

Le système est gonflé et ne peut plus suivre l'expansion de l'entreprise. J'ai accumulé une dette technique et je souhaite la restituer. La technologie utilisée est trop ancienne pour être maintenue et développée. Les coûts de maintenance sont gonflés, je souhaite donc améliorer l'efficacité.

Exemples de raisons stratégiques techniques

À l'avenir, je veux faire XXX Il y a une différence entre la réalisation de la stratégie du système et le système actuel.

Créer une stratégie système à partir des informations collectées

Une fois les informations rassemblées, l'étape suivante consiste à décider comment résoudre le problème. La même chose est vraie même s'il n'y a pas de définition dite d'exigence. Entendre et ressentir la température pour obtenir une sensation approximative.

Il est organisé en des termes que l'on trouve souvent dans les livres commerciaux tels que les personnes, les biens, l'argent, les informations et le temps. Je pense que l'ampleur du changement dans l'entreprise, les coûts et le recrutement des développeurs sont des considérations importantes.

À la suite de l'examen de ce type d'élément, nous élaborerons une stratégie système.

Classification article Choses à penser
Homme Taille de l'équipe de développeurs Cela peut-il être fait par une ou 100 personnes?
Homme Compétences de l'équipe de développement L'équipe de développement peut-elle réussir? Peut-il être maintenu?
Homme Facilité de collecte des développeurs Est-il facile d'attirer des gens en embauchant?
mono Y a-t-il une contrainte d'infrastructure? Je veux utiliser le cloud, mais parfois je ne peux pas.
mono Nombre d'établissements commerciaux, échelle d'utilisateurs tels que les personnes, etc. Dans quelle mesure l'introduction
mono Coopération avec le système existant La migration est importante.
mono Coopération avec le système externe Connaissez les limites de votre système.
Argent budget Si l'idéal coûte trop cher, cela peut ne pas être possible.
Argent Échelle de l'entreprise et ses prévisions Systématiser en tenant compte de la quantité de données et de la quantité d'informations
information Relation de modèle La division du domaine peut être la division du système.
information Quantité d'informations Le fractionnement des données devrait-il être envisagé?
information La vitesse à laquelle les informations changent Si vous ne connaissez pas la vitesse du changement d'entreprise
information Nombre de tâches critiques Systèmes d'entreprise avec beaucoup de traitement de calcul
information セキュリティが必要なinformation Quelle est la quantité d'informations importantes, telles que les informations personnelles
temps 初期リリースまでのtemps Le processus de développement peut changer pendant la version initiale et l'exploitation
temps Fréquence des demandes À quelle fréquence demandez-vous des changements de système?
temps Cycle de vie du système Est-il prévu de fonctionner pendant 10 ans? Est-ce deux ans?

Tout d'abord, déterminez la portée du système.

Déterminez ensuite la classification du système cible. Il est classé comme SoR (System of Record) ou SoE (System of Engagement).

SoR est un système qui nécessite un enregistrement correct des transactions et des informations comptables.
SoE est un système qui nécessite une optimisation pour chaque utilisateur, tel que Ma page, qui est principalement utilisé par les utilisateurs.

S'il s'agit d'un système de type SoR, envisagez de sélectionner une architecture solide. S'il s'agit d'un système de type SoE, envisagez une architecture et un processus de développement pouvant être développés avec un sens de la vitesse.

Je pense que cela peut être différent pour chaque sous-système. Si vous adoptez une architecture de micro-services, c'est une chose différente.

Après avoir décidé de la classification, il était adapté au cycle de vie Déterminer une stratégie de structure du système qui répond aux exigences initiales

S'il s'agit d'un système de type SoR, je pense qu'un système monolithique peut être utilisé tant que l'échelle n'augmente pas. Les microservices sont difficiles à concevoir des transactions. Envisagez de créer une structure qui requiert l'intégrité des données.

S'il s'agit d'un système de type SoE, il devrait y avoir de nombreuses demandes de changement de système après la version initiale. Décidez que la structure de l'architecture elle-même doit également être une structure qui nécessite un ajout.

Points à considérer lors du choix d'un langage ou d'un cadre

Une fois que vous connaissez la structure du système, vous décidez du langage de développement à y comporter. Java est-il le plus courant lors de la création de systèmes d'entreprise? Il semble que les langages et les frameworks préférés des ingénieurs soient utilisés dans les startups telles que les entreprises.

Pour les systèmes de type SoR, je préfère un langage et un cadre solides, donc Java est un bon choix. Bien que les demandes de modification du système soient rares, il y a des demandes de modification régulières. Le coût d'apprentissage est un peu lourd, mais il y a beaucoup de bonnes choses que le changement de structure peut être détecté comme une erreur de construction s'il y a un type. Je pense que cela convient pour contrôler la structure et l'état.

Dans le cas d'un système de type SoE, il y a de nombreuses demandes de changements dans le flux commercial et la convivialité, donc la vitesse est nécessaire. J'aime le langage et le cadre qui peuvent être corrigés et vérifiés. Je pense qu'il est bon de construire un mécanisme qui vous permet de créer tout en recevant des commentaires sur Ruby et PHP. Même les systèmes d'entreprise doivent pouvoir répondre à la demande de vitesse comme les services Web.

Choses communes et importantes

Bien sûr, vous pouvez obtenir la fonctionnalité lors du choix d'un langage ou d'un cadre. Les trois suivants sont les plus importants.

Quel que soit le type de système que vous créez, il n'a de sens que si vous pouvez le faire fonctionner et le maintenir. Il y a aussi une tendance dans les cadres. Le cadre que vous avez choisi lors du développement peut être rappelé cinq ans plus tard.

Par conséquent, il n'est pas possible de sélectionner un langage ou un cadre qui ignore le flux technique. Il faut faire un choix qui ne se trompe pas dans le flux technique, pas dans la mode.

Le cadre est peut-être obsolète, mais vous devez faire des choix pour améliorer les compétences de vos ingénieurs. À mesure que le niveau de compétence de l'ingénieur augmente, le système restera sain et pourra être facilement reconstruit. Et les ingénieurs qui souhaitent utiliser un cadre de flux technique peuvent se réunir. (Les ingénieurs n'aiment pas les anciens frameworks ... les nouveaux frameworks sont motivants)

Ces dernières années, je pense qu'il y a aussi un tel aspect que le nom Scala est soulevé en refaisant un grand système. (J'aime Scala!)

Vous êtes également responsable de l'achèvement et de l'exploitation du système. Comment équilibrer cela est la vitrine de la compétence de l'architecte.

finalement

Même pour les systèmes d'entreprise, le flux des affaires est rapide. Même si vous choisissez une architecture aux premiers stades du développement, elle n'est pas toujours correcte dans le cycle de vie du système.

Dans le domaine de l'aide sociale aux personnes handicapées, qui est l'activité de Ritalico, il est difficile de soutenir le système car le système national est encore en train de changer.

Nous visons une architecture facile à casser et à refaire en détail.

Recommended Posts

Éléments à prendre en compte lors du choix de l'architecture d'un nouveau système
Comment penser la conception de classe (division) dans un système d'entreprise (1)
Points à surveiller lors de la création d'un framework
Comment penser quand on comprend soudainement les génériques
Points à prendre en compte lors de la mise à niveau de Tomcat sur un système Web utilisant Oracle
Une note quand j'étais accro à la conversion d'Ubuntu sur WSL1 en WSL2
Éléments à prendre en compte lors de l'exécution d'un travail spécifié à l'aide de Spring Batch
Choses à oublier lors de l'interception d'une requête avec Android WebView # shouldInterceptRequest
Réfléchir lors de l'introduction d'une nouvelle bibliothèque
Passer de SQLite3 à PostgreSQL dans un nouveau projet Ruby on Rails
Comment donner MAX + 1 ID aux données enregistrées lors de l'ajout d'un nouvel enregistrement
Que faire lorsque "call'Hoge.connection 'pour établir une connexion" apparaît sur les rails c
Remarques sur la marche à suivre lorsqu'une exception WebView ClassNotFoundException se produit dans JavaFX 12