What Is Architecture? Concepts, Classifications, and the COLA Application Architecture

What is Architecture?

It is difficult to give a precise definition, but architecture can be described as an abstract description of the entities in a system and the relationships between them.

Architecture originated from building construction; as human activities required division of labor, systems are split according to principles that facilitate parallel work by different roles.

Why Do We Need Architecture?

Any system, from large aircraft to a small e‑commerce feature, requires architecture.

As quoted from *System Architecture: Product Design and Development of Complex Systems*, a well‑structured creation outperforms an unstructured one.

Some agile ideas advocate “no design, just work”, hoping good architecture will emerge naturally, but in practice engineers rarely refactor code that merely works.

Architect's Responsibilities

The most important value of an architect is to "simplify complexity"; designs that make a system more obscure are questionable.

The architect’s job is to train their thinking to understand complex systems, decompose and abstract them so that other participants (designers, implementers, operators) can easily grasp the system.

Software Architecture

Software architecture is a blueprint of a system. It describes abstract components that directly constitute the system and the connections that define component communication. During implementation, these abstract components are refined into concrete classes or objects, often linked via interfaces.

Software architecture provides a high‑level abstraction of structure, behavior, and attributes, consisting of component descriptions, interactions, integration patterns, and constraints. It maps requirements to structure, defines organization and topology, and supplies basic design principles.

The core value of software architecture is to control complexity; it does not prescribe a specific layering or methodology.

Software Architecture Classifications

With the growth of the Internet, systems must support billions of concurrent users, making architectures increasingly complex. The author classifies software architecture into:

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

Application Architecture : designs the application layer structure, interfaces, and data exchange protocols, controlling complexity while meeting non‑functional requirements.

Distributed System Architecture : solves load balancing, service registration/discovery, messaging, caching, and distributed databases, balancing CAP trade‑offs.

Data Architecture : standardizes data definitions and processing, builds unified big‑data platforms, and creates maintainable data assets.

Physical Architecture : concerns hardware placement, data‑center layout, network topology, and server types.

Operations Architecture : plans, selects, and deploys operational systems, establishing standardized operation processes.

Layered Architecture

Layering separates responsibilities based on roles and code organization. A typical layered diagram is shown below.

CQRS

CQS (Command Query Separation) was introduced by Bertrand Meyer. It divides object methods into two categories:

Command : returns void and changes the object’s state.

Query : returns a result without changing state and has no side effects.

Hexagonal Architecture

Proposed by Alistair Cockburn in 2005, it solves problems of traditional layered architecture by separating the system into an internal hexagon (business logic) and an external hexagon (driving logic, infrastructure).

Adapters are of two types: Driving Adapters (active) that initiate operations, and Driven Adapters (passive) that respond to those operations.

Onion Architecture

Similar to hexagonal, it isolates the core domain from infrastructure, adding layers such as Application, Domain Service, Domain Model, and Infrastructure, enabling easy replacement of tools and avoiding vendor lock‑in.

Dependency direction is strictly outward: outer layers depend on inner layers, while inner layers have no knowledge of outer layers.

COLA Application Architecture

COLA is an open‑source application architecture developed by the author’s team, incorporating classic architectural ideas, standardized design, and extensibility via an archetype approach.

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

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 send notifications; it can also directly access the Infrastructure layer if needed.

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

Infrastructure Layer : provides tunnels (abstract data sources such as MySQL, NoSQL, search engines, file systems, SOA services), configuration, and common utilities.

Extension Design

When a system grows, many if‑else statements appear. Beyond strategy patterns, COLA introduces two concepts: Business Identity (a unique identifier for a business scenario, e.g., "ali.tmall.car") and Extension Point . The combination forms an Extension Coordinate , uniquely determining an implementation.

This mechanism enables multi‑tenant, multi‑business, and multi‑scenario extensions at the framework level.

Standardized Design

COLA defines conventions for module structure, package layout, and naming to reduce ad‑hoc complexity and enforce consistency across the codebase.

COLA Overview

COLA adopts port‑adapter (hexagonal) decoupling, onion‑style domain‑centric design, and uses CQRS to separate command and query responsibilities, enhancing extensibility via extension points and metadata.

The request processing flow combines CQRS, extension points, and metadata to handle commands and queries efficiently.

Core Message : All presented architectures share the same core principle – separating core business logic from technical details to achieve maintainability and flexibility.