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.
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.
Configuration requise
Personnellement, j'aime la méthode d'analyse RDRA car elle est basée sur un modèle. Je l'utilise pendant mes études car il donne une meilleure vision de l'ensemble du système du point de vue de la détermination de l'architecture. Technique de définition des exigences basée sur un modèle Zenji Kanzaki
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.
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é.
À 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.
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.
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.
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.
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