Second, the agile view of architecture design
Through the introduction of the previous chapter, we have a roughly understanding of agile and methods. From this chapter, we have begun research on architecture design in software development. Remember, we don't study architecture design for architecture design, our purpose is to use agile methodology.
Architecture design is a trade-off. One problem always has a variety of solutions. And we must determine the only solution for the unique architecture, which means we have to make a weigh between different contradictions. Our process can always see a lot of contradictions: open and integration, consistency and specialization, stability and ductility, etc. Any pair of contradictions originate from our different expectations of software. However, to meet the requirements of our desired software stable operation, we will inevitably affect the expectations of our software easy to expand. We hope that the software is simply clear, but it has added the complexity of our design. No software can meet all requirements because these requirements have natural mutex. And the basis of the quality of our evaluation architecture design can only be rationality based on different requirements, and make the rationality of weighing.
aims
We want a good architecture to:
· Reuse: In order to avoid duplication of labor, in order to reduce costs, we hope to reuse the previous code, the previous design. Reuse is one of our constant pursuit, but in fact, it is not so easy to do this. In reality, people have made a lot of work in the architecture reuse, and the results of the work are called framework, such as Windows window mechanism, J2EE platform, etc. But in terms of business modeling, the effective framework is very small.
· Transparent: Sometimes, in order to improve efficiency, we hide the implementation details, and only present the interface of our customers to customers. In this way, specific implementations are transparent to customers. A specific example is that we use JSP TAG technology instead of JSP's embedded code because our HTML interface personnel are more familiar with TAG.
· Extension: Our thirst for extension is the variation from demand. Therefore, we need architectures to have certain ductility to adapt to future possible changes. However, as mentioned above, ductility and stability, ductility, and simplicity are contradictory. So we need to weigh our investment / output ratio. A architecture with appropriate and ductility is designed.
· Simplified: A complex architecture is difficult to test or maintenance. We hope that the architecture can be as simple as possible in the case of satisfying the purpose. But simple understanding does not seem to have a clear definition. The use model can make the design simple, but this is based on the design mode. For people who don't understand design patterns, he will think that this architecture is complicated. For this situation, I can only say to him, go see the design model.
· Efficient: No matter what system, we all want the architecture to be efficient. This is especially important for some specific systems. For example, a real-time system, a high-visitive website. These values are technical efficient, sometimes we refer to efficiency is efficient. For example, a information system that only dozens to 100 visits is only necessary to use EJB technology, which requires our comprehensive assessment.
· Safety: Safety is not the focus of our article discusses, but it is a very important aspect of the architecture.
rule
In order to achieve the above object, we usually need to develop some simple rules for architecture design:
· Function decomposition
As the name suggestion, it is to break the function. why? It is difficult for us to reach reuse because we write procedures often in a function of repetition, but there is a slight difference. Many times we can't get temptation, complete a small number of modifications with copy paste. This behavior is resolute in XP is not allowed. XP promotes "Once and Only Once", the purpose is to eliminate the phenomenon of this copy. In order to do this, we usually decompose the function to fine grain. Many design ideas have promoted small classes, which is this purpose. Therefore, the number of classes and methods in our procedures will grow, and the average code of each class and method will decline. However, how do we know how this degree should grasp? About this question, there is no clear answer to see personal skills and specific requirements, but in general, we can use a simple verb phrase to name or The method is, it will be a better classification method.
We use the rules of functional decomposition to help improve reuse, because we have improved the accuracy of each class and method. This is the principle of nature. We study the main direction of nature is to decompose substances. Our ideas can also be applied to software development. In addition to reuse, functional decomposition can achieve transparent objective, because we have used the rules of functional decomposition, each class has its own individual features, so that we can focus on this class itself, No excessive class is involved.
· Determine the coupling between different types according to the actual situation
Although we always hope that the coupling between the class is relatively low, we must objectively evaluate coupling. The system cannot always be loosely coupled, and it will definitely can't do anything. And what is the basis for our decision coupling? Simply put, it is to determine the degree of coupling based on the stability of the demand. For the need for high stability, it is not easy to change, we can completely be well coupled (we discuss the coupling between the classes, but in fact, the function block, module, and the coupling degree is also Same), because this can improve efficiency, and we can also use some better techniques to improve efficiency or simplify code, such as internal technologies in Java. However, if the demand is very likely to change, we need to adequately consider coupling problems between classes, we can think of a variety of ways to reduce coupling, but inductive, not more than an abstract level to isolate Different classes, this abstraction level can be a specific class or an interface or a group of classes (such as beans). We can use a sentence in Java to summarize the idea of reducing coupling: "Programming, not for implementation."
Different coupling are designed to achieve transparent and extended extensions. For class customers (caller), he does not need to know too much detail (implementation), he only cares about his (interface). In this way, the target class is a black box for the customer. If the interface is stable, then how to expand it, it will not have a lot of impact on customers. In the past, the problem that issued a whole body can be relieved and even avoided.
In fact, we carefully observe the 23 design patterns of GOF, without a mode idea is not to solve problems from increasing abstract hierarchies. Similarly, when we observe the Java source code, we can also find that there is a lot of abstract levels in the Java source code. In the first look, they don't do anything, but they have a significant role in the design of the system.
· It's good enough.
In the previous chapter, we talked about agile methods. We value the problems that were just enough. Now we have a complicated design and a simple design in the same way, which can also meet the needs. One better. From an agile point of view, it must be the latter. Because the current demand is only 10, your design can meet the needs of 100 items, can only say this is a waste. You don't consider cost problems at design time, do not consider cost problems, you are not responsible for development organizations, and is not responsible for customers. · Application mode
The writing idea of this article comes from the model research. Therefore, the shadow of the pattern thinking can be seen everywhere. The mode is a very good way to organize, propagate ideas, and we can learn other people's experience through patterns. A good pattern represents the results of a problem study, so we apply the model to the architecture design, which can greatly enhance the stability of the architecture.
abstract
The essence of the architecture is its abstraction. It includes two aspects of abstraction: business abstraction and technology abstraction. Architecture is a model of the real world, so we must first have a deep understanding of the real world, and then we must be able to skilled application technology to realize the real world to model mapping. Therefore, we are difficult to design a good architecture in the case where the business or technical understanding is insufficient. Of course, when we found a question: How can I understand enough to understand enough? I don't think there is no absolute criterion.
Once, a friend asked me: His system has changed now, and the original design workflow architecture cannot meet the present requirements. He hopes to design a good workflow architecture to adapt to different changes. But he found that this did not disturb a Lotus Notes. I feel two problems after listening to his question:
First of all, his development team has no experts in the workflow field. Although his customers understand their workflow, lack sufficient theoretical knowledge to refer the workflow to an abstract point. Obviously, although he has technical talents, he does not have enough experience in the workflow business itself. Therefore, the prerequisite for designing the system as Notes does not exist.
Second, what is the purpose of developing a workflow system. The original workflow system is not working well, the reason is a change. Therefore, there is only the motivation of the improvement of the workflow system. However, after all, Notes is developed to meet all the workflow systems in the world, and his current application is definitely not this level.
Therefore, although the best business abstraction is not done, we can do the best business abstraction at a specific purpose. For example, our workflow may change is a change in the working path of the work. We can make an abstraction of the path of the workflow, design a workflow architecture that can dynamically change the path.
Sometimes, although we have lacking in terms of technology and business, there is no way to design a good architecture. But we can learn from the experience of others and see how other people are solved. This is the model we mentioned earlier. Don't think patterns as a hard solution, it is just a way to solve the problem. Martin Fowler once said: "The difference between the model and business components is that you will trigger your thinking."
In the "Analysis Mode" book, Martin Fowler mentioned the difference between analysis and design. Analysis is not just a use case lists all the needs, and the analysis should also go to the back of the surface needs to obtain mental models about the nature of the problem. Then he attracted the concept of concept model. The concept model is similar to what we are discussing. Martin Fowler mentioned an interesting example. If you want to develop a software to simulate a table ball game, then use the case to describe the needs of various needs, it may result in a large number of motion trajectories. If you don't understand the essence of hidden movement laws after surface phenomenon, you may never develop such a system.
About architecture and abstract issues, a case in which a measurement mode in the later article can be visually illustrated.
Some misunderstandings of architecture
We spent some space to introduce some knowledge of the architecture. Now go back to another topic. For an agile development process, what is the architecture means, how should we face the architecture. Here we must first clarify some misunderstandings:
· Misunderstand 1: Architecture design requires strong technical ability. From a certain extent, this sentence does not have a big error. After all, the stronger your ability, and the chance to design outstanding architecture will rise. But there is no strong connection between ability and architecture design. Even the ordinary programmers, he has the same capacity to design an architecture that can achieve the target.
· Misunderstanding 2: Architecture is designed by specialized designers, designing blueprints are implemented. The reason why us will think that the architecture is a designer's work, because we like to make software development and construction projects. However, both of these are actually a great difference. The key is that the architectural design has long history, which has developed a perfect theory that can be verified by certain theories (such as mechanical principles). However, for software development, the correctness of the architecture design can only be verified by writing code. Therefore, many seemingly perfect architectures often have problems when implementing.
• Misunderstanding 3: The perfect architecture is designed at the beginning. This way is the most traditional pre-design method. This is also a design way for XP. The main reason is that the perfect architecture in the beginning is in self-deception. Because the basic hypothesis of this is the invariance of demand. But the demand is not unchanged (see the details of the demand, please refer to "Practice of Demand"). The disadvantage of this is that we limit the shape of the entire software at first. When we realize, though we find that the original design has a mistake, but it is not willing to face reality. This makes the software deformed growth. Originally some simple issues, but because of the means of the architecture, it becomes very complicated. This example we can often see, for example, software complexity caused by compatible previous versions. In 2000, the security issues of TCP / IP networks also reflected the severity of this problem from one side.
· Misunderstanding 4: After the architecture blueprint is given to the programmer, the schema designer's task is completed. Like misunderstanding, we borrowed the experience of construction projects. We see architects to hand over the design of blueprints to the construction staff, and the construction staff will build an exact same building in accordance with the drawings. Thus, we also try to use this model in software development. This is very important. Software development lacks a common language that can fully eliminate the communication between designers and programmers. Some people say that UML is not? UML's design philosophy is good, you can reduce communication barriers. But if you want to completely solve this problem, UML can't do it. First of all, the programmer has personalized thinking, he will understand the design in his own thinking, because from design to implementation is not a mechanical labor, or a knowledgeable labor (this and the work of construction Different). In addition, for programmers, he is also very likely to make certain changes to the design map according to their own ideas, which is a very normal one. Worse, programmers often compare their own assumptions, and they will have the exclusion of those who have not appreciated.
Architecture design process mode
Usually we think the model is used in software development, architecture design. In fact, this is just an aspect of the pattern. The definition of the pattern tells us that the mode describes a solution for a specific environment. This particular environment is often repeated, making a better solution for us to effectively solve similar problems in the future. In fact, this similar such thinking is also present in management. Documentary solution called structural problems. So, we can use the ideas of the pattern in other aspects, and the best application is the process mode and organizational mode. In our article, we are limited to discussion process mode. The process we discussed is limited to object-oriented software development processes. We call it OOSP (Object-Oriented Software Process). Because our process needs support for object-oriented characteristics. Of course, we can use our practices in the development of non-OO, but in order to achieve the best results, I recommend you use OO technology.
So, how should we avoid these misunderstandings, or in other words, how agile software development is schema design. There are several process modes here:
Figure 2. Agile architecture process mode overview (high-level)
In the next space, we will introduce a variety of process modes one by one. Then stand in the global perspective to analyze the relationship between the various modes, and incorporate it into a schema design.
Agile architecture design
We said that the process pattern listed here is agile, and we will verify this in each chapter on the next chapter. The various process patterns we listed are not fully charged, because some techniques are suitable for architectural design in various agile methods, and some methods are not suitable for architectural design. Therefore, we will ask yourself a few simple questions before using a method and technology:
· What is the value of this method / skill?
· How much investment does this method / skill need? It is estimated to be estimated from the creation, maintenance, training.
· Compare the investment and value of this method / skill, is it worth we adopt?
· Is there any other value / input than a higher method / skill?
In our article, each method / skill discussion has answered the top three issues, as for the fourth issue, I hope that there is a peer to tell me.
