Architecture is a common term for programmers. If you want to become an architect, you must have a clear understanding of architecture concepts. Otherwise, there will definitely be a lot of loopholes and problems while developing architectural solutions, which will negatively affect your interviews, promotions and team leadership.
Let's take a look at the definition of architecture in Wikipedia:
A software architecture is a set of structures that describe a system in the abstract, along with the rules for building those structures. These structures include: software elements, the relationships between the elements, and their properties.
In this definition, the core concepts are system, element, and relationship.
systems
In software architecture, a "system" is a complex whole of interacting parts that work together to accomplish a specific function or task, and architecture design is an abstract description of a system.
key constituent
"Elements" are the basic units that make up a system, usually subsystems, modules, and components.
- A subsystem is a part of a larger system that has specific functional responsibilities and can usually operate independently of the overall system. Each subsystem can contain multiple modules or components and is usually organized around a specific business area or technical function.
- A module is a logical unit in a software architecture that encapsulates a set of related functions or services. Modules typically interact with other modules through well-defined interfaces, supporting the design principles of high cohesion and low coupling.
- Components are self-contained, programmable, reusable, language-independent software units. Software components can be easily used in assembled applications and are the smallest units that can be deployed independently.
Some people may be confused about the concept of modules and components. Simply put, modules are divided from the business logic dimension, and components are reused from the technical dimension. The following will also use an example to illustrate the difference between them.
guanxi
"Relationships" refer to the ways in which elements of a system (e.g., subsystems, components, modules, classes, etc.) are connected and interact with each other. These relationships define how the elements collaborate and how they work together to achieve the system's functionality.
Let's take a new retail SaaS system as an example and explain the concepts:
- Subsystems include: online mall subsystem, POS cashier subsystem, order management subsystem, commodity management subsystem, customer management subsystem, warehouse management subsystem, distribution subsystem, centralized inventory subsystem, customer service subsystem, and procurement subsystem.
- The order fulfillment system can be divided into the following modules from the business dimension: C-end fulfillment service module, order dispatching module, order management module, picking management module, shipping management module, reverse fulfillment module and so on.
- The Order Management module relies on technical components such as Mysql, Redis, Elasticsearch, security components, etc. from a technical dimension.
- Subsystems, modules, and components may have relationships that work together to accomplish system functions through collaborative relationships.
Architecture Views and Perspectives
In the course of our work, we often hear the following statement:
- The product owner said that the current business architecture is too complex and needs to be carefully sorted out.
- The technical lead says that the project is complex and needs to do a review of the architectural solution.
- The R&D manager said that this spike campaign solution requires a high concurrency architecture solution.
- First-line R&D said, Internet big factories all use microservice architecture, I want to learn microservice.
What exactly is meant by the architecture mentioned above? Are these statements right or wrong?
Actually, all of the above is true, just taking a different perspective.
Because complex systems involve a large number of stakeholders, such as customers, product managers, R&D, sales, operations, management, and so on. Due to different backgrounds and perceptions, everyone views the system from different perspectives and in different ways.
To control complexity, we need to design a set of architectural descriptors and categorize and define them so that each has its own focus and each stakeholder can quickly access the information of interest.
In order to accomplish this goal, the concepts of view and perspective need to be understood first.
Architecture Perspective
What is perspective? In plain English, it's where you stand to see.
Let's take the urban system as an example, what do you see when you stand on one of the city's roads?
You can see a few buildings, a few rows of trees, a few large roads, bustling with some people.
But what do you see when you sit in an airplane and look at it?
You can see a piece of property, you can see mountains, you can see rivers and lakes. So what you can see has a lot to do with where you stand to see it, and it also affects the granularity with which you see things.
If you compare a viewpoint to a coordinate point, it requires a set of coordinate systems, which usually have 4 dimensions: breadth, depth, view type, and time.
Breadth refers to the breadth of how things are viewed. In the case of business processes, for example, depending on the starting point, sometimes you need to look at processes within a department, sometimes you need to look at collaborative processes across multiple departments, and sometimes you need to look at end-to-end cross-departmental processes.
Depth refers to the view of things, to reach which level of detail, for example, look at the business process, need to see the organization level, departmental level, or a post of specific operational steps. Look at the software system, need to see the system level, module level, or a line of code.
Breadth and depth generally interact with each other, if the broader the breadth of view of things, then the level will be more abstract, which is also complementary to the design of the organizational structure, the general top management to look at the problem is very comprehensive, but do not pay attention to the details of the front-line executives, the details of the problem is very well understood, but the perspective is very narrow.
A view type is a collection of concerns tailored to the stakeholder, as described in more detail below.
The time dimension is better understood as the point in time at which things are viewed, past, present, or future.
Architecture View
What is a view? In plain English, it's what you want to see.
A view is a collection of concerns tailored to the stakeholder.
Again using the city system as an example, the commuter who wants to catch the morning rush hour is concerned about which route is the fastest, so he needs a map of the subway bus routes.
The tenant who wants to rent an apartment, his concern is what neighborhoods are near his company and how much the rent is, so he needs a pair of rental maps.
The worker who wants to unclog a sewer is concerned with how the sewer is lined up, so he needs a map of how the sewer is lined up.
In the same city system, the focus of different roles is completely different, and the information they want to get is also completely different. If you mix all the information together without view segregation, the result is that the information is too complicated, and it is difficult for everyone to get the information they want.
Similarly, different stakeholders look at the focus of the software system is also very different, in order to distinguish the focus of different people, the birth of a lot of software view of the classification method, the more famous "4 +1" view, TOGAF's business architecture, application architecture, data architecture, technical architecture and other view of the classification method.
We focus on the TOGAF view types: business architecture, application architecture, data architecture, and technology architecture.
Among them, business architecture is the soul, application architecture, data architecture, technology architecture are to support the existence of business architecture, the latter three are also collectively referred to as IT architecture.
- Business Architecture: In order to achieve its business strategy, an enterprise structurally expresses its business as a comprehensive, multi-dimensional abstract model of its business capabilities, end-to-end value delivery, information, and organizational structure, the relationships between them, and their relationships to strategy, products, tactics, project execution, and stakeholder relationships.
- Application Architecture: Based on the business architecture, the hierarchical structure of the application system is designed, including the specification of the division of components such as system, application, module, component, etc., their definitions, boundaries, mutual interaction protocols, and the relationship between them and business activities.
- Data Architecture: Data architecture describes a set of models, policies, rules, and standards that determine how data is acquired, stored, distributed, integrated, and used in systems and organizations. Data architecture is a very important piece of architecture area in enterprise architecture, which usually includes 3 architectural processes, conceptual model design (designing the business conceptual model), logical model design (designing the logical relationships between models and their own attributes), and physical model design (designing the technical implementation details of the data).
- Technical Architecture: The technical architecture describes a series of deployable software packages, hardware capabilities, and the collaborative relationship between them, through which the enterprise's needs for business, data, and application services can be supported, and they include, but are not limited to, the IT infrastructure, middleware, networks, communication facilities, computing power, hardware standards, and so on.
With views and perspectives, we can separate concerns and break down complex problems so that the complexity of each localization is kept within an acceptable range.
At the same time, the team has a unified cognitive coordinate system, which further leads to business standardization. Based on business standardization, by separating the invariant points from the change points, we can refine reusable components and quickly respond to changes in business requirements.
This article has been featured on, my tech site: Inside there are, algorithm Leetcode detailed explanation, interviews eight stock text, BAT interview questions, resume templates, architecture design, and other experience sharing.