Understanding Software Architecture: Concepts, Classifications, and the COLA Application Architecture

Architecture is an abstract description of the entities in a system and the relationships between them, originating from building design and evolving to help divide a target system according to principles that enable parallel work by different roles.

Every system, from aircraft to an e‑commerce feature, needs an architecture; a well‑structured creation outperforms an unstructured one, and relying solely on "no design" in agile practices is unrealistic because engineers rarely refactor code without clear incentives.

An architect’s most valuable contribution is to simplify complexity, making the system understandable for designers, implementers, and operators.

Software architecture provides a high‑level abstraction of a system’s structure, behavior, and attributes, describing components, their interactions, integration patterns, and constraints, ultimately controlling complexity rather than prescribing a specific layering or methodology.

The article classifies software architecture into several domains:

Business architecture – top‑level design influencing organization and technical architecture.

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

Distributed system architecture – addresses load balancing, service registration, messaging, caching, and CAP trade‑offs.

Data architecture – standardises data definitions, formats, and builds unified big‑data platforms.

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

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

Typical application architectures include:

Layered architecture – a conventional role‑based separation of concerns (see image).

CQRS (Command Query Responsibility Segregation) – separates commands (state‑changing) from queries (read‑only).

Hexagonal (port‑adapter) architecture – splits the system into an internal core (business logic) and external adapters (driving and driven).

Onion architecture – adds multiple layers (Application, Domain Service, Domain Model, Infrastructure) to the hexagonal idea, keeping the core independent of infrastructure.

The COLA (Component‑Oriented Lightweight Architecture) framework, open‑sourced at https://github.com/alibaba/COLA , builds on these classic patterns and introduces a refined three‑layer design:

Presentation Layer : receives 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 directly access the Infrastructure layer if needed.

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

Infrastructure Layer : provides Tunnel abstractions for data sources (MySQL, NoSQL, search, files, SOA services), configuration, and common utilities.

Extension design in COLA introduces two key concepts:

Business Identity – a unique identifier for a business or scenario, represented by a BizCode (e.g., ali.tmall.car.aftermarket ).

Extension Point – a hook where each business identity can provide one or more implementations; the combination forms an Extension Coordinate (see diagram).

Specification design enforces consistent module and package structures, naming conventions, and component划分, reducing randomness and complexity.

The core mission of application architecture, echoed by layered, hexagonal, onion, and COLA designs, is to separate core business logic from technical details, allowing the former to be reusable, understandable, and independent of replaceable infrastructure.

In summary, the essence of modern software architecture is to keep "God’s work to God, Caesar’s work to Caesar," ensuring clear boundaries between business concerns and technical implementation.