By Zhang Jianfei, Senior Technical Expert at Alibaba
What is an architecture? It is difficult to give a clear definition of architecture. In fact, no standard definition is available for it. Zhang Jianfei, an Alibaba senior technical expert, believes that architecture is an abstract description of the entities in a system and relationships between them. Today, Zhang Jianfei talked about the core mission of the application architecture. Let's take a look at what he had to say.
The word architecture was originally a construction term. With the development of human society and the need for a division of labor, systems were divided according to certain principles. These principles of separation facilitated cooperative work among different roles. The term architecture was used for the scope of these different roles and their interconnections.
Architectures are required for systems, from large systems such as airplanes to the smallest functional component in an e-commerce system. According to the book System Architecture: Strategy and Product Development for Complex Systems, a well-structured creative activity is better than a non-structured creative activity.
However, many developers now advocate no design for greater agility. They think it is fine just to get started on the work. They think that architecture will naturally emerge during iteration. However, this is a bit too optimistic. In reality, engineers have little motivation to reconstruct and optimize their code once they get them to work.
As architects, our most important task is to make complex things simple. Any architecture that makes things more complex and makes the system more confusing and difficult to understand implies the necessity of improvement.
In this case, architects must refine their own thinking to better understand complex systems and make these systems easier to understand through deconstruction and abstraction. We should strive to build an easy-to-understand architecture so that others that work with the system (such as designers, implementation engineers, and operators) easily understand it.
Software architecture is a draft of the system. The software architecture describes the abstract components that directly constitute the system. The connections between components clearly and fully define their communication. In the implementation phase, these abstract components are refined into actual components, such as specific classes and objects. In the object-oriented field, the components are generally connected through APIs.
The software architecture provides an advanced abstraction of the structure, behavior, and attributes of a software system. It consists of component descriptions, the interactions between components, models for guiding component integration, and the constraints of these models. The software architecture not only displays the relationship between software requirements and software structures but also specifies the organization and topology of the entire software system, providing some basic principles that are available while making design decisions.
The core value of the software architecture lies in one function: the control of complexity. It does not refer to a specific layered structure or methodology, such as anemic design or DDD.
Before introducing application architecture, let's take a look at the classification of software architectures.
With the development of the Internet, current systems need to support the needs of hundreds of millions of users who shop, communicate, and entertain themselves online. In turn, the corresponding software architecture has become increasingly complex. In addition, the meaning of the term software architecture expands. Today, we cannot simply use the term "software architecture" to cover all work related to software architectures. In my view, software architecture can be divided into the following:
Layering is a common practice that organizes code units based on their roles (responsibilities) in a system. The following figure shows a common layered structure.
Command Query Separation (CQS) originated from the concept put forward by Bertrand Meyer (the father of Eiffel and the man who proposed OCP). The basic idea in this is that the methods of any object can be divided into two categories:
The hexagonal architecture was proposed by Alistair Cockburn in 2005 to solve the problems brought about by the traditional layered architecture. In fact, it is also a layered architecture but is organized in the internal-external format instead of the up-down format, as shown in the following figure.
Hexagonal architecture is also known as port-adapter architecture. This name is more appropriate from the containers' perspective. Hexagonal architecture divides a system into two parts:
The internal part includes the business logic of the application, whereas the external part includes driving logic, infrastructure, and other applications of the application.
Adapters are divided into two types, as shown in the following figure. The UI adapters on the left are called driving adapters because they initiate operations on the application. The adapters on the right that are connected to backend tools are called driven adapters because they only respond to the operations of driving adapters.
The onion architecture and hexagonal architecture are based on the same idea. They both emancipate the application core from the need to pay attention to the infrastructure by writing the adapter code and avoid the penetration of infrastructure code into the application core. In this way, the tools and communication mechanisms used by the application are easily replaced. As a result, the application is not chained to any specific technologies, tools, or vendors.
The difference is that enterprise applications with onion architecture have more than two layers. It adds additional layers identified in the domain-driven design process to the business logic. These layers include Application, Domain Service, Domain Model, and Infrastructure.
In addition, use mock instead of real infrastructure and communication mechanism applications to facilitate testing.
In onion architecture, the dependency direction is clearly defined:
COLA architecture is an application architecture developed in-house. It is now open-source. When designing COLA, we fully incorporated the excellent ideas of other classic architectures. In addition, we added a specification design and extension design modes and used the Archetype method to solidify the architecture so that it can be quickly used in development.
Find the open-source code of the COLA architecture at https://github.com/alibaba/COLA.
The COLA layer is an improved three-layer architecture. The traditional business logic layer is divided into the application layer, domain layer, and infrastructure layer. The following figure shows the traditional layered architecture on the left and the COLA layered architecture on the right.
The scope and significance of each layer are as follows:
1) Presentation Layer: This layer receives web requests in Rest format, routes the requests to the application layer for execution, and returns the View Model, which is generally carried by a Data Transfer Object (DTO).
2) Application Layer: This layer obtains the input, assembles the context, verifies the input, calls the domain layer for business processing, and sends a message notification if necessary. The layers are open. If necessary, the application layer can directly access the infrastructure layer.
3) Domain Layer: This layer encapsulates the core business logic and provides external computing and processing for the business logic through Domain Service and Entities functions.
4) Infrastructure Layer: This layer includes Tunnel, Config, and Common. Here, we use the Tunnel to abstract all data sources, including databases (MySQL and NoSQL databases), search engines, file systems, and SOA services. Config is used to configure applications, whereas Common is a common tool class.
In a simple scenario with only one business, there is no great need for extensibility. This is because most systems start with a single business, where extension design is often ignored at the beginning. However, as business scenarios become more complex, a large number of if-else logic appears in the code. In addition to the conventional policy mode, consider providing a unified extension solution at the architecture level.
In extension design, we applied two important concepts, business identities and extension points.
A business identity is the unique identifier of a business or scenario in the system. In the actual implementation, BizCode represents business identity. BizCode adopts a method that is similar to Java package namespaces. For example, we can use "ali.tmall" to indicate the Alibaba Tmall business, use "ali.tmall.car" to indicate Tmall's car business, and use "ali.tmall.car.aftermarket" to indicate the post-market scenario for Tmall's car business.
One or more ExtensionPoints can be implemented for each business or scenario. That means an extension is uniquely identified by a business identity plus an extension point. This combination of a business identity and extension point is called an ExtensionCoordinate, as shown in the following figure.
In this way, with a business identity and extension point, we can implement extension and customization for different tenants, businesses, and scenarios at the framework level. The entire Alibaba business mid-end applies this idea to support multiple businesses.
Anything is a combination of rules and randomness. The significance of specifications is that we can solidify rule-based factors to minimize complexity because consistency reduces the system complexity. This is true of everything from naming to architecture. The architecture itself is a set of specifications and constraints. Violating these constraints damages the architecture.
COLA formulates a series of specifications, including the module structure, package structure, and naming convention. For example, all applications that use COLA must follow the module division shown in the following figure:
Like the hexagonal architecture, COLA advocates the application of the port-adapter idea to decouple technical details. Like the onion architecture, COLA sees the domain as the core of the architecture and reverses the dependency direction of the domain layer through dependency inversion. Ultimately, it establishes the module relationships shown in the following figure.
From another perspective, see how COLA applications process and respond to requests. COLA uses CZR to separate commands and queries and uses extension points and metadata to improve application extensibility. The entire processing procedure is shown in the following figure:
Considering all the preceding application architectures, one thing they have in common is the separation of core business logic and technical details.
The core responsibility of the hexagonal architecture, onion architecture, and COLA architecture is to split and decouple core business logic and technical details. Consider what would happen if the business logic and technical details were mixed together. All the code would be written in ServiceImpl, and the first few lines of code would perform validation, the next few lines would perform the conversion, followed by several lines of business processing logic code. In between the business logic code, we might need to obtain more data through RPC or Daos and, after obtaining the data, write a few more lines of conversion code followed by more business logic. Then, we would have code for storage, messaging, and other functions.
Even for simple businesses, this programming method would result in a high complexity and maintenance difficulty.
Therefore, the core mission of the application architecture is to separate business logic from technical details. The core business logic should reflect domain models and domain applications. Moreover, it can be reused and easily understood. The technical details assist in business functions and can be replaced when necessary.
How to Code Complex Applications: Core Java Technology and Architecture
3 posts | 0 followers
FollowApache Flink Community China - April 23, 2020
OpenAnolis - December 8, 2022
Adrian Peng - April 23, 2021
Alibaba Cloud Community - October 10, 2023
ApsaraDB - December 5, 2018
Alibaba Clouder - June 28, 2017
3 posts | 0 followers
Follow
Platform For AI
A platform that provides enterprise-level data modeling services based on machine learning algorithms to quickly meet your needs for data-driven operations.
Learn More
Epidemic Prediction Solution
This technology can be used to predict the spread of COVID-19 and help decision makers evaluate the impact of various prevention and control measures on the development of the epidemic.
Learn More
Architecture and Structure Design
Customized infrastructure to ensure high availability, scalability and high-performance
Learn More
Machine Translation
Relying on Alibaba's leading natural language processing and deep learning technology.
Learn More
