当前位置：网站首页>A simple architecture design logic ｜ acquisition technology

A simple architecture design logic ｜ acquisition technology

2022-06-21 19:52:00 【nginx】

1 background
Technical proposal design and review is an important part of version iteration , In general, version iterations are delivered , The technical scheme is designed in 2-3 God , Granular requirements or independent projects , The time of this link will be moderately prolonged , But the overall time is still relatively tight . It is relatively difficult for technical students to produce high-quality technical solutions in a short time , In this way, it is difficult for reviewers to understand the technical scheme design in place 、 And give reasonable suggestions . This paper presents a technical solution design logic for requirements iterative delivery to solve this problem , Its core idea is to adopt Use case driven design , be based on “ Deductive method + From top to bottom ” To design technical solutions .
2 Outline design logic
The technical scheme design logic of this paper , Use case driven design . First, identify the key use cases from the requirements , Then construct a sequence diagram involving top-level service interaction for use cases , Then, the design of each service interface implementation will be developed from top to bottom .
      
  • Key use case identification ： A use case is a complete process in which users or external systems interact with the current system , It considers the complete interactive process of solving user problems from the perspective of users . This is the first step in driving software design , With key use case identification , You can design for each use case . In this way, the whole technical scheme design has integrity and derivation logic .  
  • Use cases involve top-level service interaction timing design ： Top level services are the outermost services , You can understand it as RPC Service or HTTP service . A complete user interaction process will involve the collaborative completion of multiple top-level services , The interaction sequence diagram defines the service interaction sequence that satisfies the use case 、 Service interface definition 、 The general implementation logic of the service . This step is an outline design , It doesn't go deep into the design of the service , Instead, it prefers the definition of the interaction contract between services （ service function 、 Service interface 、 Service interaction ）. Next, the service interface implementation scheme design can be deduced from the interaction sequence from top to bottom .  
  • Service interface implementation design ： In the 2 Step in the outline design , The functions of the service are clearly defined 、 Service interface definition , This step starts from the functional and non functional problems to be solved by the service , In particular, the definition and satisfaction of non functional problems often affect the design of implementation schemes , Such as reliability 、 Scalability issues 、 Maintainability issues . for instance , For scalability , Can be split into scale scalability 、 Business scalability . Scale scalability depends on the performance of the service itself and the horizontal scalability of the service , Therefore, how to improve the performance of the service and the horizontal scalability of the service will have a great impact on the design of the service interface implementation . here , We may design the solution based on the functional problem , Add cache components , To improve performance .
above 3 Point is simple use case driven design logic . Next, I will introduce the more complete design logic .
notes ： Use case driven design , It's very important , It can not only be used in design , Also coding 、CR、 Stability guarantee plays a very important role , for instance , At present, our CR It is a case by case review , Each use case first introduces the top-level service interaction sequence diagram , Again Review Code , The review efficiency and results have been greatly improved .
3 Complete design logic
The starting point of architecture design is the user problem , Form a solution from the user problem , The final landing becomes our product demand . Rationality of product demand , It will be up to the user whether the question is accurately defined 、 Whether the user problem solving path matches 、 Whether the business processes and rules involved in the user problem solving path are reasonable . Technical students focus on application architecture 、 Technology Architecture 、 The data architecture , These three architectures can be designed according to reasonable derivation logic . A relatively simple and clear derivation path is divided into four stages 、 Nine steps , As shown in the figure below .

   
      
  • Demand analysis ： Structural analysis of requirements , Identify the problem that needs to be solved 、 Implementation path 、 The business processes and business rules involved in the implementation path , Finally, the participants and key use cases of the system are extracted . Be careful ： The key use cases of the system are very important , It is the first step of the whole technical scheme design , Use case driven design .  
  • Application Architecture Design ： Starting from the key use cases of the system , Outline all use case scenarios for requirements , The application involved in the use case 、 Services and their dependencies , Then the interaction sequence diagram of the service involved in the use case is designed in detail , And define the interface definition and non functional requirements of the service . Application architecture is a high-level design , It helps the whole team understand the use cases involved in requirements and the specific interaction process of services involved in use case implementation , Defines the application 、 Implementation contracts between services . Be careful ： The use case service interaction sequence diagram here only involves services and core processes , Not too detailed to the specific implementation of the service , That is to say, each service has only one Lifeline, Each step in it is briefly described .  
  • Technical architecture design ： Expand from the service interface defined in the application architecture , Design the implementation of service interface , The functionality of the service interface implementation needs to be analyzed 、 Nonfunctional requirements , Accurately identify the problems to be solved in the implementation of the service interface , Then design the corresponding solution , In particular, the satisfaction of non functional requirements needs to be ensured through the design of a reasonable technical architecture . such as , Solve the problem of live broadcast inventory 、 Solve the problem of oversold inventory 、 Solve the problem of distributed consistency of bids 、 Solve the problem of modular expansion of product details 、 Solve the problem of real-time collection big data query , The definition of these problems in use cases can lead to reasonable solutions , Graphically represent the solution , Form the technical architecture design as a whole . Nonfunctional requirements , Can be classified as reliability requirements 、 Maintainability requirements 、 Scalability requirements 、 Efficiency and cost requirements, etc .
         
    • Reliability requirements can be achieved by SLA Define the goal ,SLA It can be divided into SLO、SLI, For example, the response success rate of the service interface at the specified response time 、 Distributed transaction consistency ratio, etc , Then design corresponding scheme to ensure .   
    • The core of Maintainability requirement is to control complexity , Try to use simple design to meet maintainability . Mature architectural styles can be adopted 、 Design patterns are applied in service implementation , Like layering 、 pluggable （ modularization ）、 Pipe filter 、 Combination mode, etc .   
    • Scalability requirements focus on the expansion of scale and business rules , The expansion of scale requires horizontal expansion and contraction , Need to meet at least the stateless design , The extension of business rules can apply the architecture style and design pattern of extension classes .   
    • Efficiency and cost requirements are constraints on technical architecture design , That is, the implementation of services should consider the cost , Be as cost-effective as possible .   
       
  • Data architecture design ： Starting from the service interface implementation scheme , Design a reasonable storage architecture to meet the functional and non functional requirements of services . The data architecture needs to clearly describe the dependent relational data storage 、 Columnar data storage 、 Cache 、 Indexes 、 Offline computing 、 Real time computing, etc , And the specific data model （ It can be used ER The picture shows ）, Besides , You also need to consider transaction performance 、 Data analysis performance and other requirements .
The architecture design is based on Use case driven design , adopt “ Deductive method + From top to bottom ” For deriving design . First , From business requirements to IT framework （ Application Architecture 、 Technology Architecture 、 The data architecture ） It is designed by layer derivation . secondly , Application architecture comes from global use case scenarios and use cases involve service interaction , It is an outline design ; Technical architecture and data architecture are the scheme design of the specific implementation of the application architecture service interface definition , It needs to be designed for the functional and non functional requirements of the service interface implementation ; From application architecture to technical architecture and data architecture, it is from top to bottom （ Or from total to minute ） The derivation of .
The detailed design logic of each part can be referred to ： standard - Technical solution design , This paper introduces how to do requirement analysis in detail 、 How to do application architecture design 、 How to do technical architecture design 、 How to do data architecture design .
4 Two key types of graphs ： Use case diagrams and sequence diagrams
   4.1 Use case diagram
Three parts ： participants 、 Use cases 、 The relationship between actors and use cases .
participants ： Not specifically people , It's outside the system , Using the system or The role played in interacting with the system ⻆ color . So the participants can be people , It can be something , It can also be time or other systems and so on .
Use cases ： Is a description of a set of action sequences including variables , System Perform these actions , And produce observable results that convey the value of a particular participant .
Relationship ： The relationship between actors and use cases mainly includes association 、 inductive ( generalization )、 contain 、 Expand and rely on .

The relationships in the use case diagram are described as follows ：
A） relation ： Represents the relationship between actors and use cases ;
B） generalization ： Indicates between participants 、 Between use cases The relationship between , A use case can be specifically enumerated as one or more subuses example , This is called use case generalization ;
C） contain ： Represents the relationship between use cases , One of the use cases ( Basic use cases ) The behavior of contains another use case ( Include use cases ) Of Behavior . It is used to decompose the functions represented by a more complex use case into smaller steps ;
D） Expand ： Represents the relationship between use cases , It is used to expand the use case and enhance the basic use case ; Extended use cases are when specific conditions occur , Use cases that will be executed .
4.2 Sequence diagram
Sequence diagram is an object behavior modeling based on interaction , yes UML Used to describe Methods of information interaction between objects , It is a model to describe the cooperative relationship between objects .
The sequence diagram is used to capture the time sequential interaction between objects in the operation of the system , It consists of lifelines and messages .
The sequence diagram represents the interaction relationship as a two-dimensional diagram . The vertical is the time axis , Time goes down the vertical line . The horizontal axis represents the individual pairs in the collaboration The class element of an image ⻆ color . Class element ⻆ Color is represented by lifeline . When an object exists when ,⻆ Color is represented by a dotted line , When the object's procedure is active when , The lifeline is a two lane line . Messages are used from the lifeline of an object An arrow to the lifeline of another object indicates . The arrows are in chronological order in Figure From top to bottom .

The sequence diagram elements are described as follows ：
A）⻆ color ： user 、 External systems, etc .
B） Objects and lifelines ： The name of an object can be a class name 、 Object name 、 class + Object name , The lifeline is a dashed line indicating the time the object has lived .
C） Activity bar ： On the dotted line of the lifeline, a movable bar can be used to represent The beginning and end of an act , It is usually represented by a rectangle .
D） news ： The behavior of an object is called a message , Object calls another object The behavior of is to complete a message delivery . It is divided into ： Simple message 、 Synchronous cancellation Rest 、 Asynchronous messaging . Besides , There are also self invocation messages 、 The return value of the message .
E） Interaction box ： Options opt、 Choose alt、 loop loop、 parallel par etc. .
5 Reference templates and examples
The following is the technical proposal reference template defined in the bid , Different templates cut and adjust the design logic . For version iterations , Most requirements design can be adopted V3 Version of the way to design . The corresponding reference examples are attached here , For your reference .
Templates

Logical structure

Technical proposal reference template -V3： stay V2 Simplify on the basis of , Integrate the content of technical architecture into use case design
          
  • Application Architecture Design
              
    • Use cases involve service interaction sequence diagrams         
    • Service interface definition         
    • Service interface implementation scheme design         
    • Use case diagram         
    • Use case implementation design       
          
     
          
  • Data architecture design
              
    • ER chart         
    • DDL        
    • Storage architecture design         
    • Data structure design       
          
Technical proposal reference template -V2： stay V1 Simplify on the basis of , Omit business process analysis
          
  • Application Architecture Design
              
    • Use case diagram         
    • Application and service planning         
    • Use cases involve service interaction sequence diagrams         
    • Service interface definition       
          
     
          
  • Technical architecture design
              
    • Service implementation technical scheme design       
          
     
          
  • Data architecture design
              
    • ER chart         
    • DDL        
    • Storage architecture design         
    • Data structure design       
          
Technical proposal reference template -V1： A complete template from requirements analysis to data architecture design
          
  • Demand analysis
              
    • The business process         
    • Use case diagram       
          
     
          
  • Application Architecture Design
              
    • Application and service planning         
    • Use cases involve service interaction sequence diagrams         
    • Service interface definition       
          
     
          
  • Technical architecture design
              
    • Service interface implementation technical scheme design       
          
     
          
  • Data architecture design
              
    • ER chart         
    • DDL        
    • Storage architecture design         
    • Data structure design       
          
          6. Conclusion
This paper explores the use case driven architecture design logic , The core idea is to adopt Use case driven design , be based on “ Deductive method + From top to bottom ” To design technical solutions , Help developers clarify the design ideas of technical solutions and improve the quality and review efficiency of technical solutions . The simple and clear derivation path behind the complete architecture design is divided into four stages 、 Nine steps , Simple and practical , As shown below .

The outputs of each stage are as follows .
      
  • Output of demand analysis stage
         
    • Business flow chart （ Activity diagram or flow chart , Swimlane or non swimlane ）   
    • Use case diagram    
       
  • The application architecture design phase produces results
         
    • application 、 Service planning    
    • Use cases involve top-level service interaction sequence diagrams    
    • Service interface definition    
       
  • å The technical architecture design stage produces results
         
    • Design scheme of service interface implementation    
       
  • The data architecture phase produces results
         
    • Storage scheme implemented by service interface    
    • ER chart    
      
* writing /Lorry

Focus on Technology , Every Monday, three or five nights 18:30 Update technology dry goods
If you think the article is helpful to you , Welcome to comment and forward some likes ～


原网站

版权声明
本文为[nginx]所创，转载请带上原文链接，感谢
https://yzsam.com/2022/172/202206211810319240.html

边栏推荐

猜你喜欢

随机推荐