Why Architecture Matters: Unpacking Application Design Principles and the COLA Framework

What Is Architecture?

Architecture is an abstract description of system entities and the relationships among them, as defined by Alibaba senior expert Zhang Jianfei.

Why Architecture Is Needed

Any system—whether an aircraft or a small e‑commerce component—requires architecture to enable parallel work, manage complexity, and support scalable development.

Role of an Architect

An architect’s primary value is to simplify complexity, turning intricate systems into understandable structures for designers, implementers, and operators.

Software Architecture

Software architecture is a high‑level sketch of a system that describes abstract components, their connections, and how they are refined into concrete classes or objects during implementation. It defines the structure, behavior, and attributes of a software system and guides design decisions.

Core Value of Software Architecture

The central purpose is to control complexity; it is not tied to any specific layering or methodology.

Software Architecture Classification

Key categories include:

Business Architecture – top‑level design influencing organization and technical layers.

Application Architecture – defines layers, interfaces, and data‑exchange protocols to keep complexity manageable.

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

Data Architecture – provides unified data definitions, standards, and a platform for large‑scale data processing.

Physical Architecture – maps software components onto hardware, networks, and servers.

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

Typical Application Architecture

Layered architecture is a common practice that separates responsibilities by role. See the diagram below.

CQRS (Command Query Separation)

CQRS separates methods into commands (which change state and return no result) and queries (which return data without side effects).

Hexagonal Architecture

Also known as ports‑and‑adapters, it isolates the core business logic from technical details by defining internal and external sides.

Onion Architecture

Similar to hexagonal architecture but adds multiple concentric layers (application, domain, infrastructure) and enforces that outer layers depend on inner ones while inner layers remain unaware of the outer.

COLA Application Architecture

COLA is an open‑source framework that blends ideas from hexagonal and onion architectures, uses CQRS, and introduces extension points and metadata to improve extensibility. It adopts a three‑layer design (presentation, application, domain, infrastructure) with clear responsibilities.

Layered Design in COLA

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

Application Layer : Validates input, assembles context, invokes the Domain layer, and may send notifications.

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

Infrastructure Layer : Provides tunnels (data sources such as MySQL, NoSQL, search, files, SOA), configuration, and common utilities.

Extension Design

Uses a business identity (BizCode) and extension points to uniquely identify extensions. Combining a BizCode with an extension point yields an extension coordinate , enabling per‑tenant or per‑scenario customization.

Standardization Design

COLA defines conventions for modules, packages, and naming to reduce randomness, improve consistency, and lower system complexity.

Core Mission of Application Architecture

The overarching goal is to separate core business logic from technical details, making the former reusable and understandable while allowing the latter to be swapped out as needed.

Processing a Request in COLA

COLA employs CQRS to separate command and query responsibilities, uses extension points and metadata for extensibility, and follows the layered flow illustrated below.