Why Good Software Architecture Matters: From Basics to the COLA Framework

Architecture

What is architecture?

Architecture is difficult to define precisely, but it can be described as an abstract representation of entities in a system and the relationships between them.

It originates from building construction: as human activities required division of labor, systems are split according to principles that enable parallel work for different roles.

Why do we need architecture?

Any system, from an aircraft to a single e‑commerce feature, requires design and architecture. A well‑structured design yields better creative outcomes than an unstructured one.

While some agile ideas promote “no design, just work,” in reality engineers rarely refactor code that merely works, making a solid architecture indispensable.

Architect’s responsibilities

The primary value of an architect is to simplify complexity. Good architecture makes systems easier to understand for designers, implementers, and operators.

Software Architecture

Software architecture is a blueprint of a system, describing abstract components and their connections. During implementation, these components become concrete classes or objects, often linked via interfaces.

It provides a high‑level abstraction of structure, behavior, and attributes, consisting of component descriptions, interactions, integration patterns, and constraints, linking requirements to structure and guiding design decisions.

The core purpose of software architecture is to control complexity, not to enforce a specific layering or methodology.

Software Architecture Classification

Based on modern internet demands, software architecture can be divided into several categories:

Business Architecture : Top‑level design defining business domains, influencing organization and technical architecture.

Application Architecture : Designed by application architects to define layer structures, interfaces, and data exchange protocols, balancing functionality, performance, security, and stability.

Distributed System Architecture : Addresses load balancing, service registration, messaging, caching, and distributed databases, requiring trade‑offs among CAP properties.

Data Architecture : Focuses on unified data definitions, standards, and building a maintainable data asset platform.

Physical Architecture : Concerns hardware placement, network topology, and server infrastructure.

Operations Architecture : Plans, selects, and deploys operational systems, establishing standardized operations.

Typical Application Architectures

Layered Architecture

Layered architecture separates responsibilities into distinct layers, as illustrated below.

CQRS

CQRS (Command Query Responsibility Segregation) separates methods into commands (which change state) and queries (which return data without side effects).

Command: No return value, modifies object state.

Query: Returns result, does not modify state.

Hexagonal Architecture

Hexagonal (port‑adapter) architecture separates the core business logic (inside the hexagon) from external drivers and infrastructure (outside), using adapters to connect them.

Adapters are classified as:

Driving Adapters (active): Initiate operations on the application.

Driven Adapters (passive): Respond to the application’s actions.

Onion Architecture

Onion architecture shares the same goal as hexagonal: isolate the core domain from infrastructure, allowing easy replacement of tools and avoiding vendor lock‑in.

It adds multiple layers identified during domain‑driven design (Application, Domain Service, Domain Model, Infrastructure).

It also enables the core to run without real infrastructure by using mocks for testing.

Dependency direction is strictly inward: outer layers depend on inner layers, while inner layers are unaware of outer ones.

Outer depends on inner.

Inner does not know outer.

COLA Application Architecture

COLA is an open‑source application framework developed by Alibaba, incorporating classic architecture ideas with additional specifications and extensions.

COLA’s layered design improves the traditional three‑layer model by splitting the business logic layer into Application, Domain, and Infrastructure layers.

Layer responsibilities:

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

Application Layer : Handles input, assembles context, validates, invokes Domain layer, may send messages, and can directly access Infrastructure if needed.

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

Infrastructure Layer : Provides tunnels for data sources (DB, search, file system, SOA services), configuration, and common utilities.

Extension Design

When business scenarios become complex, simple if‑else logic proliferates. Beyond strategy patterns, COLA offers a unified extension mechanism.

Two key concepts:

Business Identity : A unique identifier for a business or scenario, expressed as a BizCode (e.g., "ali.tmall.car").

Extension Point : A hook where each business identity can implement one or more extensions. The combination of Business Identity and Extension Point forms an Extension Coordinate.

This design enables framework‑level customization for different tenants, businesses, and scenarios.

Specification Design

Standardizing rules reduces randomness and complexity. COLA defines conventions for module structure, package layout, and naming.

COLA Overview

COLA adopts port‑adapter decoupling like hexagonal architecture and the domain‑centric approach of onion architecture, resulting in the component relationship diagram below.

When handling a request, COLA uses CQRS to separate command and query responsibilities, leverages extension points and metadata for extensibility, as shown in the flow diagram.

Core of Application Architecture

All discussed architectures share a common goal: separating core business logic from technical details .

This separation makes the core logic reusable, understandable, and replaceable, while technical details remain interchangeable.