Hello everyone, I am Han Cao 😈, a grass code ape 🐒 who has been working for one and a half years. If you like my article, you can follow ➕ and give a thumbs up. Please grow up with me
“This is the 20th day of my participation in the First Challenge 2022. For details: First Challenge 2022.”
background
This is the sixteenth article in my Architectural Cleanliness series, and the first in software architecture.
Clean Architecture Series:
- Hancao’s column on the Way to Neat architecture
Software architecture
What is software architecture
The word architecture sounds very mysterious. When we talk about it, there is always a feeling of pushing up, giving people a feeling that I am standing in the C position of the conference room guiding the country to make important decisions and technical analysis.
This is of course, after all, advanced to the architecture level is the goal of most technical people, such as me, the most arrogant little garbage ~
This is when the three questions of the soul appear:
- What is software architecture?
- What does a software architect do?
I don’t think it’s tea and paper
- When does the software architecture work?
First of all, software architects themselves must be the most capable programmers who insist on coding. They can not only take on their own development tasks, but also gradually guide the entire team toward a system design direction that maximizes productivity.
They must continue to undertake programming tasks, if they do not personally suffer from the trouble caused by system design, they will not be able to experience the pain of poor design, and then enter the lost.
The architectural quality of a software system is determined by its builders, and the essence of software architecture is:
- How do you divide your system into components
- Arrange the arrangement of components
- Communication between aligned components
The purpose of software architecture is to better manage these components:
- The development of
- The deployment of
- run
- maintenance
If you want to design a system that’s easy to move things along, the strategy is to keep as many options in the design as possible for as long as possible.
There is a myth here that software architecture is meant to make the system work, but it doesn’t!
First of all, the highest priority of software architecture design must be the normal work, this is no doubt, we think, a system can not work, how beautiful tightly designed are meaningless. But the quality of software system architecture has little to do with how well the system works. After all, the world is full of software that works, and well-designed systems are only the tip of the iceberg.
Therefore, the most troublesome aspect of software architecture is how to make the system better for development, deployment, and subsequent extension.
The development of
A software system that is difficult to develop usually doesn’t last long, just like a relationship that is difficult to maintain, Hancao said.
So one of the roles of a system architecture is to make it easy for its development team to develop it.
Here we consider two cases:
- System A
A small team of five people who develop very quickly in a system with no clearly defined interfaces and components may think that the system architecture is a barrier to rapid early development.
- System B
When a software system is developed by five different teams, with seven developers on each team, development cannot proceed without the system being divided into well-defined components and solid interfaces.
Therefore, different teams should adopt different architectural designs based on the actual situation.
The deployment of
The higher the deployment cost of a system, the lower its availability, Hangrass said. Just like the AABA cheat code that needs to go up, down, left, right, left and right doesn’t really have one button to boot.
So one-click deployment should be a goal of our software architecture. However 🦢, early deployment strategies are rarely considered, which often results in systems that are easy to develop but difficult to deploy.
As an example, in the early development of a system, a developer may decide to adopt a “microservice” architecture that has many advantages:
- Clear component boundaries
- The interface stability
- .
This is great for development, but there is a large number of microservices at deployment time, and the connection and startup time between these microservices can be a source of system errors.
If software architects had considered these deployment issues early on, they might have intentionally reduced the number of microservices, adopted an architecture that mixed in-process components with external services, and adopted a more integrated connection management approach. “Here is what the book says, cold grass does not know much about micro services.”
run
“Software architecture doesn’t affect operations as much as it does deployment and maintenance,” He said. “We can add hardware to operations.” Just like the size of the clothes does not affect me to wear it, it becomes a tights.
For a poorly architected system that is inefficient, we usually just need to add more storage and servers to get it done. After all, capitalists also know:
Hardware is cheaper than labor
Software architecture has another important role in the operation of the entire system:
A well-designed software architecture should clearly reflect the requirements of the system at run time
Put it another way:
That is, the architecture should set the use cases, functions and necessary behaviors of the system as visible entities to developers, simplifying their understanding of the system, which will provide great help for the development and maintenance of the whole system.
maintenance
Of all the aspects of a software system, maintenance costs are the highest, Hancao said. Keeping up with the never-ending demands for new features and fixing system bugs will take up the lion’s share of human resources. Just as it’s easy to start a relationship, it’s hard to maintain it.
The main cost of system maintenance focuses on two things: “discovery” and “risk”
- confidential
The cost comes primarily from our mining of existing software systems to determine the best place and way to add power or fix problems.
- risk
When we make these changes, there is always the possibility that new problems will arise, and that possibility is the cost of risk.
We can dramatically reduce both of these costs with a well-crafted architecture. By dividing the system into components and isolating them with stable interfaces, we can clarify how new functionality will be added in the future and significantly reduce the likelihood that changes will cause harm to other parts of the system.
Keep optional
Software has behavioral value and architectural value, as I mentioned in my previous article. Software was invented because we needed a flexible and convenient way to change the behavior of machines. The flexibility of software depends on the overall state of the system, the arrangement of components and the way they are connected. How do we maintain this flexibility in software?
- As many options as possible
So which options should we keep on the table?
- The details that don’t matter
Basically, all software systems can degrade into two main elements: policy and detail.
- Policy is the embodiment of all the business rules and operational processes in software, so it is the real value of the system
- Details are those that allow the people operating the system, other systems, and programmers to interact with the policy without affecting the behavior of the policy itself
Including 1/0 devices, databases, Web systems, servers, frameworks, interactive protocols…
The goal of the software architect is to create a system shape that takes policy as its most basic element and decoubles the details from the policy to allow for the delay or deferment of details in specific decisions. Such as:
- There should be no need to choose a database system in the early stages of development because the high-level strategy of the software should not care which database is used at the bottom
If we intentionally free ourselves of the details when developing high-level strategies, we can defer or postpone detailed implementation-related decisions, because later in the project we have more information to make sound decisions.
A good software architect should aim to maximize the number of options available
conclusion
The main goal of software architecture design is to support the full life cycle of a software system. A well-designed architecture makes the system easy to understand, modify, maintain, and deploy. The ultimate goal of software architecture is to maximize programmer productivity while minimizing the total operating costs of the system.
Remember, it's all about profit, software architecture too!
Furthermore, a good architect carefully isolates the high-level policy of the software from its underlying implementation, decoupling the high-level policy from the implementation details so that the policy part does not need to care about the underlying details at all, and certainly does not depend on them in any way. In addition, a good architect should design a policy that allows the system to defer implementation details decisions as late as possible.
✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨
Youth never knows heaven and earth
Conceit and talent are everywhere you look
Pretentious as it is
I was honest
I love such a boy
Humble and arrogant
Proud and calm ☀️
✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨
Your likes and attention are my constant motivation, you can add my wechat: HancAO97, invite you to join the group, learn and communicate together, become a better front-end engineer ~