Architecture Design Practice Summary

1. First, we need to make the demand function list, pick out the points that affect the architecture as the key requirements, and complete the implementation in this architecture. To complete the most critical functions, we will not waste too much time on all aspects. However, the functions excluded in this period are not a key requirement, and even adjustments will not affect the architecture. Only when the key requirements are clear can the architecture be determined to hold those issues and clarify the scope of requirements. And full review.
2. Identifying non-functional requirements still focuses on key requirements. If you do not have time, do not. Non-functional requirements must have models and scenario descriptions. During the architecture design process, whether or not non-functional requirements are met is considered in real time. Only when the functions are not determined can the later architecture determine the methods used to achieve the key needs. The key point is to allow all members to participate in the discussion. This not only gives all members an understanding of their needs, but also gives all members the wisdom to avoid building behind closed doors by architects.
3. A string of processes to draw out all the key processes required. The results will also be adjusted after the previous day, but the details should be as detailed as possible. The simplest method should be used for implementation. If the process string is complex, it indicates that there is a problem and it needs to be re-painted. Otherwise, it will be a waste of time and complicated and prone to problems. It is critical that all members participate in the discussion.
4. To begin writing the outline design, the outline design can use Graphs without words. In addition to writing 5 views, key technologies and solutions should also be written to implement specific functions. Coding specifications should be described (Java, sonar, and running logs ). It is critical that all members participate in the discussion.

 

So far, we hope that the next architectural design will reduce the learning curve and increase productivity.

 

The following is a summary of each view:

1. Interface view: displays the systems, external systems, internal systems, and external network elements, shows the interface relationships between each system and network element, the direction of the interface, the protocol, and the business carried by the system (in the appendix of the list ).
2. Logical view: shows the number of internal systems, the number of external systems, the relationship between the system and the system, and the functional points of the internal system, which can be described layer by layer in the form of a large package.
3. Deployment view: How many systems are there, how each system is deployed, how many servers are there, and what message interaction is there between each system, including the operating system, interface system, database system, disk array, data storage system, and log system.
4. Data View: where data is stored, not only DB, but also who the data is related to, what the circulation relationship is, what the circulation business is (using the list appendix), and how the data is stored, (File/MC/q), where are operation logs recorded. Which systems are only descriptions, not the focus of this figure. This figure focuses on data storage and transfer description. Design the database tables to be completed in this period.
5. Implementation view: Technology (view layer, implementation layer, persistent layer), package (project package relationship and project directory), pom file (jar dependency, lifecycle ).
6. Process view: Describe the Network Element and user, who initiates, who receives, and who works. Describe the start and end of the system with the lifeline. Describes the key processes.
7. Status migration diagram: Describes the starting position, intermediate status, final status, status flow, and direction. consider exceptions. The operation failed, how to handle it or remind me.
8. Use Case view: Describe the role and describe the use case package. The Use Case points are described inwards by the package.

 

Architecture Design Practice Summary