Agile thinking: Methodology in Architecture Design (8)-Architecture Vision

Introduction:Starting from this article, we will enter another different topic, which is different from the previous model focused on organization, process, and method.
Shao's model focuses more on design. However, the shadows of processes and methods are still vague in our discussion. The Architecture Vision is a very simple model, and it takes a short time in software development. But this does not mean
The architecture vision is not important. On the contrary, it will be an indispensable part of the design process.

Context

At the beginning of a single iteration, we have collected the requirements for a single iteration.

Problem

Architecture and analysis design are inseparable. Sometimes it is difficult to clearly define the architecture, but the architecture should be able to describe the entire software. The architecture includes all aspects of the software, but every design detail always needs to be considered separately. At this time, there will be inconsistencies between the design details and the architecture.

The design conflicts between different parts of the architecture design are easy to occur. The probability and frequency of occurrence are directly proportional to the team size and inversely proportional to the frequency and Effect of communication. During many project development
We found multiple codes with the same function, because the author of the Code does not know that others have implemented this function. This may be a waste of effort, but if the design conflicts between different modules lead to the absence of software
During normal operation, we need to sit down and take a good look at what happened.

Solution

We need to build an architecture vision. The architecture vision should be able to provide a global view of the software, including all the important parts, defining the responsibilities and relationships between each part, and defining the software design needs
The principle of compliance. The design of this architecture vision should meet the needs of the source model. That is to say, part of the division and part of the design are carried out according to the needs. At the same time, the architecture vision should be able to meet
Other features of the architecture, such as simplicity, scalability, and abstraction. Simply put, we regard the architecture vision as a mini architecture design.

As we discuss the Architecture Vision in a single iteration, the overall architecture vision is constantly changing. This is natural, because the Architecture Vision represents the design of the architecture, and the evolution of the Architecture Vision represents the evolution of the architecture design.

The Architecture Vision is relative to a specific scope. Within a specific scope of software functions, talking about the architecture vision has practical significance, such as the overall situation of the software or a sub-module. In this specific range
After the Architecture Vision is established, all design principles in this scope will not violate the Architecture Vision. This is very important and is the greatest use of the Architecture Vision. With this guarantee, we can ensure the design
Consistency and validity. Any design can be integrated into the original architecture to make the software more perfect, rather than more dangerous.

Of course, it is not easy to do this. It is particularly important to note that the Architecture Vision Model is only a road to achieving this goal and is not a sufficient condition. If the vision cannot be used in the design
There is a problem if it is enough to implement its will, or if the vision is formulated, it is almost impossible to achieve the above effect. In addition, this mode is only the first step to achieve this goal.
You will find that you still need to cooperate in many aspects.

Architecture Vision hierarchy

Based on the applicability of the architecture, we divide the Architecture Vision into several categories:

Software global

The global architecture of software is what we are most concerned about, so we will spend the most time.

The overall architecture vision of the software is generally difficult to be embodied at the code level. In fact, you will find that, even if it is embodied at the code level, the code will not have much value due to problems in reality. Because
Therefore, the architecture vision set globally for the software can be embodied in principles or pattern names and described in natural language or pseudocode. For example, you can define a three-tier architecture for a system as its vision and point out the three-tier architecture
Classification principle. Note: we need to point out the classification principle. Otherwise, the three-tier architecture does not make much sense, because the three-tier architecture varies greatly with the implementation of different platforms and developers, if not
It makes no sense to define an Operational Specification. In the Java environment, we can say:

"The client adopts the Front-end browser interface, and the business logic adopts servlet and JSP Compiling. The data from the browser to the server adopts centralized processing. The specific method is to use Front-end between the business logic and the Front-end browser.
Control Mode: receives the data transmitted by the browser and assigns it to the corresponding business logic for processing. The validity test of data is divided into two parts: the basic validity verification that is irrelevant to the business logic
Script processing. The legality verification related to the business logic is processed at the business logic layer. You can use a centralized servlet to handle errors. "

In Windows, we know that the boundaries of the layer-3 structure are different from those in Java (this will be described in detail in the next article). We can
It is very convenient for the display layer to directly manipulate data. Therefore, the Architecture Vision descriptions in Windows are different. In addition, in a non-object-oriented environment, in a distributed environment
In the Notes environment, the architecture descriptions are different.

Note that the architecture vision is developed based on different application environments, which we emphasized at the beginning of the article. The same problem has emerged here. We can use a simple example.
Deepen your understanding of this issue. In the Java environment, especially in the J2EE environment, the classic design idea is to regard a database table as a class, and each row in the table is a specific class.
Every field in the table corresponds to a variable in the class. The class generally supports the Find method to obtain instances with different data. This is a natural design concept and can be simplified through CMP and other technologies.
Tedious steps of design. However, in Windows, I believe that not many people will do this. The common processing method is to use RecordSet, that is, for a group
Record, rather than a single record. These records can be cross-table (using SQL connections) or single-table. Most programming languages in Windows support Note
Because of the record set method, writing a program based on the record set method is quite simple. Of course, we can also adopt the J2EE platform programming method, but it will lead to a surge in programming volume, and it is difficult to achieve the expected results.
Result. The difference between such platforms leads to the difference in the architecture vision.

In addition, we have noticed that our description of the architecture is not very careful enough. This is normal, because with the development, we will constantly improve the description of the architecture. For example, we can write
Front
The class framework of Controll writes several major servlets and their relationships. In this case, using UML class diagrams is a good choice. In fact, I highly recommend the architecture.
A large number of class diagrams are used in the design. However, in actual operation, most software teams have their own architectural design ideas, and what tools are used is not the main problem.

From the demand model, we learn that the architecture design comes from the demand, while the architecture applied to the software is from the most important demand. Remember the online pet store we mentioned in that Model
Example? The system adopts the MVC mode. sun's official documents show at the beginning why the MVC mode is used and what problems the MVC mode solves. Then, they begin to analyze several components of the MVC mode.
Points: Model, View, and Controll. In fact, most of the Code in MVC represents a sub-system, but at present, we are very clear about the system.
In general, what will it look like, although it is still very vague at this time.

Do not create a detailed plan in the global architecture vision, or generate a large amount of actual code. Because your architecture vision is not yet stable (we will
Will discuss stability issues), without your consent or proof. Therefore, from the perspective of the entire development cycle, the global architecture vision is evolving, modified, and improved with the iteration cycle.

How can we determine the completion of the global architecture vision? In general, your architecture design team can end up with a consensus. If the problem domain is familiar to the team, it can be solved in an hour or two.
Problem. Next, the design team will spread the architecture vision to the entire development team, and everyone will have a consistent understanding. Different opinions will be fed back, and in this iteration cycle (if the time is relatively urgent) or next time
In the iteration cycle (if the time is relatively loose.

Sub-module-level or sub-problem-Level Architecture Vision

At this time, the architecture vision is clear, because there are already clear problem domains. For example, interface design, domain model design, and persistence layer design. The vision here is essentially and global.
Our vision is almost the same, and we will not mention the specific examples. Note that you cannot violate the global vision. In terms of operation, the global vision is jointly developed by the design team, and the sub-module-Level Architecture
The vision can be assigned to the design team, and the audit should be attended by the design team. There are two advantages: one is to ensure that the sub-modules (sub-problems) do not conflict with each other or there are blank areas, and the other is
Each sub-design team can learn design experience from others.

When designing, we can also refer to other materials, such as related patterns or specifications (Interface Design Guide ). In a team with development experience, development technology is generally accumulated. These are also important materials for reference.

In our vision at this level, we will mainly talk about the coupling between submodules (subproblems. Generally, the coupling degree between sub-modules is relatively small. For example, in a MIS system
The Coupling Degree of a block is relatively small, and the degree of coupling between sub-problems is relatively large, such as permission design and finance, these functions will be used by each module. Then, we need to develop a contract for the sub-module (sub-problem)
Contact
Interface ). The contract means that this interface is formal and cannot be modified at will, because this structure will be used by other design teams. If it is modified, it will generate none for other teams.
Expected impact. The formulation and modification of contract interfaces must be approved by the design team. In addition, it is better to consider some global sub-problems in the system, such as credit
In the accounting example, we mentioned a subproblem of Interest Calculation Method in the global vision.

Code-level vision

Strictly speaking, the vision at this level is not a real vision, but a specific design. However, to ensure the integrity of our understanding of the architecture design, we should discuss it briefly. A general vision at this level
It can be represented by class diagrams and interfaces. However, in the class diagram, you do not need to mark specific attributes and operations. You only need to specify the class responsibilities and the relationships between classes. The audit of this level of vision needs to be set up
Pass by the sub-team.

The design is subdivided into this granularity, and there may be only one or two developers executing the vision design. However, the most important task is how to break down the problem and how to merge it. Decomposition is mainly based on two dimensions.
One is the problem size dimension, and the other is the time length dimension. That is to say, You (design the sub-team owner) need to split the problem into smaller sub-problems based on the size and resolution time and hand it over to different developers.
Then combine the solutions proposed by developers.

Construction Process of Architecture Vision

The source of the Architecture Vision is demand. It should be pointed out that the requirements here are mainly those aimed at the fundamental needs of the system. For example, the system is characterized by an interactive system or a distributed system. These requirements will affect the design of the Architecture Vision. Design the architecture vision based on the importance of the requirement after collecting the requirements that affect the Architecture Vision.

The design of the architecture vision does not require a complicated process or a lot of time. We have already mentioned that the main purpose of the architecture vision is to spread the design ideas in the development team. Therefore, the architecture vision includes the basic design ideas and basic design principles.

It is worth noting that there may be multiple perspectives on the architecture vision. The following describes a design model perspective. However, the actual design may also be based on the database to design the Architecture Vision. However, in the design of enterprise information systems, I recommend the design of domain classes, that is, the example discussed below.

After the Architecture Vision is designed, the focus of the problem will be on how to disseminate the Architecture Vision. To achieve the effect of achieving a unified design intent in the development team, you can consider referencing the team design model. In addition, targeted pre-project training is also an effective approach.

Architecture Mode

The architecture model is also a good source of Architecture Vision design ideas. With the in-depth research on design patterns, it is found that some of these design patterns can be expanded or changed as the basis of software design. Here
And then implement more designs. These models form an architecture model. Of course, different software architecture models are also different. In Applying
In Pattern, there is a typical Architecture Vision example:

Suppose we need to design a Distributed Interactive System. Both distributed systems and interactive systems have specific architecture modes. The former is the Broker mode, and the latter is the MVC mode. First, we need
The importance of the characteristics of the system to arrange the order of patterns. It is assumed that the distributed feature is more important. First, we should select the Broker mode as the basic mode of the Architecture:

 

Considering the interactive feature, we need to identify the Model, Controller, and View from the current basic architecture based on the features of the MVC Model. Model and
View is very simple, and is distributed in the Server and Client respectively. The Controller has two options. Assume that the Controller is deployed on the customer.
Terminal, the evolution is:

 

In this way, the basic architecture vision has emerged. If we have more requirements, we can continue to improve. However, remember that the architecture vision should not be too complex. As we discussed in the previous section
Here, although we discuss the architecture vision based on the design model, there are still many ideas about the architecture vision from other perspectives. As for how to choose an architecture vision, the key lies in the requirement.
Understanding.