In software development, the number of architectural patterns and architectural concerns has increased since the word architecture became widely used. But back to the level of “Tao”, the definition or essence of architecture remains:
Architecture, also known as software architecture, is an abstract description of the overall structure and components of software, which is used to guide the design of various aspects of large-scale software systems.
———— from Baidu Baike
Many partners who feel bored when doing business functions, such as adding, deleting, modifying, checking and developing, often imagine doing architecture as a paradise where they can concentrate on excellent technology without the interference of noisy business voices. Architecture is simply understood in terms of ox X’s performance, OX X’s TPS, high availability, how much PV it supports, etc. But these are small pieces of the architecture, not the whole picture. Before the Internet, it was all ABOUT C/S programs. There was no focus on performance or anything like that, but there was architecture. There is no structure in the world, but the larger the team, the more it needs to make an agreement on the overall rules, so that everyone can work in the same direction and avoid a lot of internal friction, so that the structure gradually formed. This road is “there is no way in the world, but because of the number of people to become a road”.
Why is a software architecture important? When we have a team of only 2 or 3 people, or even a single person, the effect of architectural prominence may not be so obvious, but if the team is large, we believe that the following phenomena will be more common:
· The new system usually does not exist independently, and generally needs to interact with the existing system. There may be many places for integration and interaction. Which integration needs to be realized by the system? At the same time, it is generally divided into multiple phases of development, how to define the boundaries of the system?
· Software system is a whole composed of multiple modules. Therefore, when there are always problems between upstream development and the module we are responsible for, no matter how much effort we make, we cannot reverse the negative effects brought by the poor quality of upstream modules. (I think people are freaking out.)
· Every time I look at someone else’s code, I always think I would write it differently. It’s better than he wrote. (for us in technology, it’s normal to feel good about ourselves :).
· In some scenarios, I have multiple scenarios in my head to implement, but don’t have much sense of which one is better than the other, and end up basically picking one.
· A certain piece of code has been maintained for too many times, especially after it has been taken over by more than one person in the middle, the code styles are different and difficult to understand.
· Similar code appears in several places, especially non-business code such as log handling. Even in a large distributed system, different subroutines use different middleware of the same type, which also leads to a large increase in maintenance costs.
· The design divergence at the boundary of two interdependent projects makes sense from both sides.
Everything has two sides. It does not mean that we should go to the other extreme through architecture. For example, in large distributed systems, it is necessary for different subroutines to choose other middleware of the same type at some point. For example, Kafka and RabbitMQ are BOTH MQ, but their value in a particular situation is not interchangeable.
Therefore, it is important for us to choose a plan with the optimal input-output ratio to Balance architecture. More on this in paragraph 4.
Beyond that, the main purpose of architecture is to allow everyone to spread and expand in the same direction, on the same standard. One is to control the lower limit of the hard standard, improve the overall shortest version, the second is to raise the ceiling level, that is, the ceiling position, to provide greater space for development. For example, when building a large building, the frame structure should be well designed and put up so that everyone can reach a consensus on what load-bearing wall can not be destroyed and what creative space can be customized. Develop independently on such a basis. This may seem like a limitation, but it is the most important task of doing architecture, and no amount of documentation, no amount of best practices, is worth a constraint. Reducing complexity and understanding is a real benefit. The most afraid of is the excessive waste of assumptions.
What’s more, the ideal country we are pursuing with architecture is a world where everyone has consensus, and architecture is a habit that everyone takes for granted, like eating and drinking water. Understand or take on projects from others as if they were written by you. This is when architecture is eliminated, just as no one teaches you how to eat now. (just imagine :).
The above mentioned is more about the purpose of architecture, so to do a good architecture, mainly is to do a good abstraction, the way of abstraction is analogy, analogy can be used to do the use case diagram. Therefore, it is suggested that we draw more pictures, through which the abstract results in the brain can be intuitively reflected in the front, and then further analyze the rationality. Two main categories of diagrams are recommended, one of which is the use-case diagram mentioned earlier. The diagram below:
The other is robust graph, as shown below:
The main objectives of the whole process are:
· Describe its interactions with external entities (systems and end users).
· Identify information and control flows between systems and external entities.
Finally attached an article before finishing the diagrams are used in software development of the article addresses, interested students can expand reading: https://www.cnblogs.com/Zachary-Fan/p/developdiagram.html.
In an ideal world, the boundaries of our programs are designed to match the business boundaries. However, as engineers, we have to bear the pressure of business requirements first and can only squeeze time to do these non-business work. As a result, the business boundaries of older projects are not always as clear as those of new ones.
This means prioritizing any architectural changes and, in particular, thinking hard about business boundaries before splitting business areas. Prioritize the benefits and risks of a split. Dividing the boundaries of the business requires more thought about how the spin-off will communicate and collaborate in the future, and then technology. Before technical factors, the following points should be considered:
· Whether it has a separate team to maintain and the potential to grow into a separate business. (Avoid sharing kernels when you don’t have to)
· There should be a clear maintenance team around the field rather than the feature to avoid being too fine-grained.
· Can existing collaboration processes be improved after splitting or combining.
· Can help distinguish core and non-core businesses and improve stability.
After the above is completed, it is necessary to choose the appropriate middleware and technical framework to meet the requirements of the technical level. This selection is mainly based on the following considerations:
· If the middleware is directly introduced into the third party, how about its maturity? Are there any big companies using it? (The affirmation of word of mouth endorsement of a big company is a big plus)
· What is the community activity recently? (Used to determine if more people are treading pits together, reducing the number and probability of each pit)
· Hard indicators: whether the hard requirements of the current scene are met. Such as performance, scalability to critical parts or future.
· Soft metrics, complexity, maintainability, etc. Here you can list the advantages and disadvantages of several competing products.
· The most important thing is to verify the above points by yourself and do some simulation work.
· If you have used it or have part of your experience that can be reused, this is a plus. After all, it is disastrous to find that you can’t hold it in the process of using it!
I have heard a sentence before, summed up very incisive. A good architecture must fit the business, so the business + technology evolved into a mathematical formula to express it can be understood as: the sum of two numbers is equal to 10, how to combine to get the largest product. It’s not 3 times 7, it’s not 4 times 6, it’s 5 times 5.
So architecture is not a rote, architecture for the sake of architecture (doing things), following the fashion, or putting on X. We should avoid being dominated by personal will. For example, if you think a particular piece of middleware is good, you will “go around with a hammer looking for a nail”. It looks good, but the costs and risks involved are ignored. There may be a better solution, or it may not be necessary to hit the nail right now.
A good architecture needs to evaluate the input-output ratio, and the one with higher returns is the one with better architecture, as shown in the formula below. Output can be understood as the benefits we get (such as reliability, security, scalability, maintainability, scalability, performance, etc.), and cost is the input we spend on transformation, such as manpower, resources, and time. And the thing to pay special attention to is risk, which is a very important thing and one that people tend to overlook, is exponential. No matter how good the solutions are, if they are all technologies that can’t be held, then the risks are infinite, leading to infinite approaches to zero on the right side of the minus sign. The final result is negative returns, and the cost of investment is wasted, and even other extra efforts are added.
All of the above concerns are the responsibility of the architect, but most importantly, the architect must be a “good coder” with ambition!! (Emphasis). A software architect, unlike an architect, is faced with an abstraction, and without practice, it is almost as good as an armchair strategist. Therefore, the difficulties and key points in the actual work should be clear, and the solution or direction can be given. In addition, only those who are familiar with the actual operation can more accurately assess the cost
Becoming a true “good coder” is your first step towards becoming an architect. Then, the need to continue to deep – wide – deep – wide rhythm to expand the territory, expand their knowledge, of course, the need to close to the current work content of knowledge, this is the second step. And that’s not the end of it. There are three things to build: business skills, communication skills, and charisma.
As an aside, purely technical architects are not as good as application-oriented architects in China. Therefore, this article is based on the functional requirements of the application architect.
Going back to the beginning of the article, there are many forms of architecture. In essence, the architectural design idea of single application is the same as that of distributed system. The so-called servitization is actually a modular idea, but the difference of dimension leads to the difference of some tools or environments used, but these are “technical” things. Optics, you’re never done learning. The road to architecture is long. Let’s keep moving forward.