Shulou(Shulou.com)06/02 Report--

There are a thousand "best architecture" patterns among the so-called thousand architects.

"Architecture" is a very common word in our industry, indicating that it must also be a word formed after a long period of polishing. What is the meaning of the word architecture? To solve what problem? Only by figuring out these two problems, can we design a good project structure.

I think the structure is similar to drawing a house design. at the beginning, when we built a small house on the first floor, we patted our forehead and thought that we started to build it any way we wanted, and it wouldn't happen in most cases. But when you want to build a building, patting the forehead may still work, but without careful consideration, it must be fraught with problems. In addition, the team size required to build a building and an one-story cabin must be different, and everyone has different standards in mind. If there is no uniform specification, the final result can be imagined. So the architecture is to set the rules and make restrictions, it is a "most reasonable decision" after weighing the gains and losses of all parties, and it guides everyone in the team to be consistent at the ideological level, so that the final product is as if it were made by one person. In addition, it can control the complexity, improve the teamwork, reduce the cost and so on.

In software development, the meaning of architecture is not just to get the team to agree, because the essence of our work is to make better software products needed to support business development, so architecture is also business-based architecture. I think it is appropriate for a good structure to foresee business development for one or two years in advance. In this way, we can pay a more reasonable price in exchange for truly achieving the effect of technology-led business growth. I believe that most people who have worked in small and medium-sized companies should have experienced the era of being pushed by business, getting stuck here every day, hanging up here, reporting errors here, and so on. When we encounter these problems, it is time to spend the cost to consider whether there is a problem with the current architecture.

How to design an architecture?

The most important thing about architecture is that it fits the business mentioned above. Any architecture that is not based on business fantasy is a hooligan.

Architecture is not as usual to write code, right is right, wrong is wrong, it is not right or wrong, it is a trade-off process. It is really difficult when we start to build the architecture from 0. Although everything is difficult at the beginning, a good beginning is half the success and will lay a solid foundation for our next work.

Here is how the author makes a framework from scratch for your reference and study:

1. Architecture is a whole-> part of the process, it is necessary to clarify what services the entire company / organization provides to the outside world. This is the top strategic structure, which is difficult or even impossible to change once determined.

two。 Divide the solution for each part, such as a service in SOA. For example, according to the company's organizational structure or products, etc.

3. Find the core and supporting functions of each solution. And form a business overview map.

4. Division must be combined for a long time, combined with the current actual resource situation to make the final decision, which is the most time-consuming point in the whole process, which determines the complexity of architecture and development cost. Ways include, but are not limited to, extracting reusable functions, combination of functions, splitting finer-grained functions to improve reusability, and so on. All these decisions should be made "just right". Never blindly follow the wind of micro-service! Never blindly follow the wind of micro-service! Never blindly follow the wind of micro-service! Say the important things three times. The finer the service granularity is, the more complex the calling link is, and whether the development cost is suitable for the team is a key point to consider as an architect.

5. Establish the mode of cooperation between each functional block, including, but not limited to, communication methods, communication protocols, dependencies, etc.

6. Finally, we should form the final overview of the architecture, which can help to consider the evolution of the architecture from a higher point of view. If you are redoing the architecture for an existing project, you need to sort out the existing project architecture as part of our thinking process above.

What are the characteristics of a good architecture?

First of all, from the mentality, there must be craftsman spirit, because the software architecture and building a house are still different, it is not in place in one step from the beginning, a good design must be repeatedly modified, from simple to complex cycle verification, constantly polishing.

In terms of direction, I think it is divided into the following points:

1. Documentation: documentation must be done throughout the life cycle of both whole and part. Sources of change include, but are not limited to, BUG, requirements.

two。 High availability: in order to improve the availability of the software as much as possible, I don't think every operator wants to see his or her work not working properly. Black box and white box testing, unit testing, automated testing, fault injection testing, improving test coverage and other ways to move forward step by step.

3. Security: the data generated in the operation of the organization are of commercial value, and it is an urgent part to ensure the security of the data. To avoid scandals like XX door. Encryption, https, etc. are common means.

4. Extensible: the design of the software adheres to the concept of low coupling and pays attention to abstraction in a reasonable place. It facilitates iterations of functional changes, additions and technologies, and supports refactoring of the architecture at the right time.

5. Fast iteration: embrace change and seize strategic opportunities.

6. A high degree of autonomy: in order to better support points 4 and 5, the advantage of a high degree of autonomy for each function is that it can be iterated quickly, and the impact on the entire system is minimized by both functional and technical iterations.

7. High reuse: in order to avoid repetitive work and to reduce costs, we want to be able to reuse previous code, previous designs. This is the most dependent on the architectural environment.

8. Verifiable: a good framework needs to take into account a variety of special circumstances and can be specifically verified.

What are the misunderstandings to avoid in the process of architecture?

When doing anything, you need to constantly re-examine it from the original point of view, so as to avoid falling into a quagmire. List a few misunderstandings that I can think of:

Myth 1: the architecture is done exclusively by architects, and business developers do not need to pay attention to it: no matter how good the architecture is, code is ultimately needed to land, and the larger the organization, the more difficult it is to land. Not only the system architecture, each solution and each project also has its own architecture, such as layering, design patterns, and so on. If each brick is not strong enough, the whole system is still at risk of collapse. As the saying goes, "a dike of a thousand miles is broken by an ant's nest."

Myth 2: after the architect has identified the architectural blueprint, the task is over: the architecture is not a castle in the air, but the architect will eventually land, but how can the architect know where the "ground" is if he doesn't go to the front line at all? How to fall steadily.

Myth: there is no best architecture in the world, only the most suitable one. What we need is not to build a car at once, but from a unicycle-- > bicycle-- > motorcycle, and finally to a car. Imagine a product that can be made in two years' time. Did the market still exist?

Conclusion

The road to architecture has a long way to go. Program design and architecture design are interoperable, and everyone can move forward from designing a program to designing a system architecture. If there is no way to start now, I recommend that you can start with the concept of domain-driven design, which is a business-oriented design approach, which can be of great help to the training and design of a landing architecture. Finally, to quote the famous saying "Yu Jun", as architects, we should have the heart of "skepticism: self-iteration".

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.