Community Blog Core Mission of Architecture in Application Development

Core Mission of Architecture in Application Development

This article gives a detailed account of application architecture and describes the need for software architecture.

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.

Why Do We Need Architecture?

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.

Responsibilities of Architects

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

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.

Software Architecture Categories

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:


  • Business Architecture: This architecture is designed by a business architect, also called a business domain expert or industry expert. Business architecture is a top-level design, the way in which it defines and divides a business affects the organizational structure and technical architecture. For example, before Alibaba established the mid-end department, the technical architectures of different business departments are separate, in which case Taobao, Tmall, Fliggy, and 1688 each had its own architecture. Then, a shared platform division was set up to integrate accounts, products, orders, and other systems, making it possible to reuse business infrastructure.
  • Application Architecture: The application architecture is designed by an application architect, who is responsible for designing application layers, formulating application specifications, and defining APIs and data interaction protocols based on the needs of business scenarios. The application complexity should be maintained at an acceptable level whenever possible, allowing it to quickly support business development and ensure system availability and ease of maintenance. In addition, the architecture must ensure that the application meets non-functional requirements, such as performance, security, and stability requirements.
  • Distributed System Architecture: A distributed system is a basic requirement of all but the smallest businesses. This system must be able to process server loads, implement distributed service registration and discovery, and provide a message system, cache system, and distributed databases. At the same time, the architect needs to strike a balance among consistency, availability, and partition tolerance (CAP).
  • Data Architecture: Data governance is a major concern for large companies. The data architecture is tasked with providing unified services and standards for data collection and data processing. It aims to unify data definition specifications, standardize data expressions, form effective and easy-to-maintain data assets, and build a unified big data processing platform to form a closed data usage loop.
  • Physical Architecture: The physical architecture focuses on the layout of software components on hardware. It includes data center construction, network topology, network distributors, proxy servers, web servers, application servers, report servers, integration servers, storage servers, and hosts.
  • O&M Architecture: Businesses must plan, select, deploy, and launch standardized O&M systems.

Typical Application Architecture

Layered Architecture

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:

  • Command: It does not return any results (void), but changes the state of the object.
  • Query: It returns results, but does not change the object status and has no effect on the system.


Hexagonal Architecture

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:

  • Internal
  • External 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.


Onion Architecture

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:

  • The outer layers depend on the inner layers.
  • The inner layers are imperceptible to the outer layer.

COLA Application Architecture

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.

Open-source Code URL

Find the open-source code of the COLA architecture at https://github.com/alibaba/COLA.

Layered Design

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.

Extension Design

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.

Specification Design

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:


COLA Architecture Overview

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:


Core of the Application Architecture

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.

0 0 0
Share on

Frank Zhang

3 posts | 0 followers

You may also like


Frank Zhang

3 posts | 0 followers

Related Products