What Is Software Architecture? Core Concepts, Patterns, and the COLA Framework Explained

What Is Architecture?

Architecture can be described as an abstract representation of the entities in a system and the relationships among them. It originated from building design and serves to split a target system according to principles that enable parallel work by different roles.

Why Is Architecture Needed?

Any system, from large aircraft to a single e‑commerce component, requires architecture. A well‑structured design yields higher productivity and maintainability, whereas a lack of design leads to chaotic code that engineers are reluctant to refactor.

Responsibilities of an Architect

The architect’s primary value is to simplify complexity. Good architecture makes the system understandable for designers, implementers, and operators by abstracting and decomposing the system into clear components.

Software Architecture Overview

Software architecture is a high‑level sketch of a system, describing abstract components and their interactions. In implementation, these components become concrete classes or objects, often connected via interfaces. Architecture provides a high‑level abstraction of structure, behavior, and attributes, linking requirements to system organization and guiding design decisions.

Software Architecture Classification

Business Architecture – defined by business architects, influencing organization and technical design.

Application Architecture – designed by application architects to control complexity, meet non‑functional requirements, and define interfaces and data contracts.

Distributed System Architecture – addresses load balancing, service discovery, messaging, caching, and CAP trade‑offs.

Data Architecture – standardizes data definitions, governance, and builds unified big‑data platforms.

Physical Architecture – concerns hardware placement, network topology, and server roles.

Operations Architecture – plans, selects, and deploys operational systems.

Typical Application Architectures

Layered Architecture

Layered architecture separates responsibilities into distinct layers. A common three‑layer structure includes presentation, application, and domain/infrastructure layers.

CQRS

Command Query Separation (CQS) divides methods into commands (which change state and return void) and queries (which return data without side effects). This principle helps keep read and write concerns separate.

Hexagonal Architecture

Proposed by Alistair Cockburn in 2005, hexagonal (or port‑adapter) architecture divides a system into an internal core (business logic) and external adapters (UI, infrastructure). Adapters are classified as driving (initiating actions) or driven (responding to core actions).

Onion Architecture

Onion architecture shares the hexagonal goal of isolating the core from infrastructure but adds multiple concentric layers (Application, Domain Service, Domain Model, Infrastructure) to support domain‑driven design and enable easy testing via mocks.

Outer layers depend on inner layers

Inner layers have no knowledge of outer layers

COLA Application Architecture

COLA is an open‑source application framework developed by Alibaba. It incorporates ideas from classic architectures, adds standardized design and extensibility, and provides an archetype to bootstrap projects. Repository: https://github.com/alibaba/COLA

Layered Design

Presentation Layer : Receives REST requests, routes them to the Application layer, and returns view models (DTOs).

Application Layer : Handles input validation, assembles context, invokes the Domain layer, and may send notifications. It can also directly access the Infrastructure layer if needed.

Domain Layer : Encapsulates core business logic via domain services and entities.

Infrastructure Layer : Provides tunnels for data sources (databases, search, files, SOA services), configuration, and common utilities.

Extension Design

COLA defines two concepts to support diverse business scenarios:

Business Identity : A unique identifier (e.g., ali.tmall.car) that distinguishes a business or scenario.

Extension Point : A hook where a business can provide one or more implementations. The combination of Business Identity and Extension Point forms an Extension Coordinate , uniquely locating an extension implementation.

Specification Design

COLA enforces a set of conventions for module structure, package layout, and naming to reduce ad‑hoc complexity. Component diagrams illustrate the required module partitioning.

COLA Architecture Overview

COLA combines hexagonal and onion principles: ports‑and‑adapters decouple technical details, while dependency inversion keeps the domain core independent of infrastructure. The component relationships are shown below.

When handling a request, COLA uses CQRS to separate commands and queries, and leverages extension points and metadata to achieve high extensibility.

Core of Application Architecture

The common thread across layered, hexagonal, onion, and COLA architectures is the separation of core business logic from technical details. Mixing the two leads to tangled code where validation, conversion, business processing, RPC calls, and persistence are interleaved, making maintenance difficult. Proper separation enables reusable, understandable domain logic while allowing technical concerns to be swapped independently.