Core Mission of Architecture in Application Development

Image for post
Image for post

By Zhang Jianfei, Senior Technical Expert at Alibaba

Introduction

Image for post
Image for post

Architecture

Why Do We Need Architecture?

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

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

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

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:

Image for post
Image for post
  • 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

Image for post
Image for post

CQRS

  • 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.
Image for post
Image for post

Hexagonal Architecture

Image for post
Image for post

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.

Image for post
Image for post

Onion Architecture

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.

Image for post
Image for post

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

Open-source Code URL

Layered Design

Image for post
Image for post

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 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.

Image for post
Image for post

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

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:

Image for post
Image for post

COLA Architecture Overview

Image for post
Image for post

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:

Image for post
Image for post

Core of the Application Architecture

Image for post
Image for post

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.

Original Source:

Follow me to keep abreast with the latest technology news, industry insights, and developer trends.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store