Fundamentals 14 min read

Why Architecture Matters: From Basics to the COLA Open‑Source Framework

This article explains what software architecture is, why it is essential, the responsibilities of architects, various classification types, common patterns such as layered, CQRS, hexagonal and onion architectures, and introduces the open‑source COLA framework with its layered design, extension mechanisms, and specification rules.

IT Architects Alliance
IT Architects Alliance
IT Architects Alliance
Why Architecture Matters: From Basics to the COLA Open‑Source Framework

What Is Architecture?

Architecture is an abstract description of the entities in a system and the relationships between them. It originated from building design and serves to split a system according to principles that enable parallel work by different roles.

Why Architecture Is Needed

Any system, from an aircraft to a single e‑commerce feature, requires a design. A well‑structured creation outperforms an unstructured one. Agile “no‑design” attitudes are unrealistic because engineers rarely refactor code that merely works.

Responsibilities of an Architect

An architect’s primary value is “simplify the complex”. The goal is to train one’s mind to understand complex systems, decompose and abstract them so that designers, implementers, and operators can easily grasp the system.

Software Architecture Basics

Software architecture is a high‑level sketch of a system. It describes abstract components and their connections, which are later refined into concrete classes or objects. It provides a structural, behavioral, and attribute abstraction composed of component descriptions, interactions, integration patterns, and constraints, linking requirements to structure.

Classification of Software Architecture

Typical categories include:

Business Architecture : top‑level design defining business domains; influences organization and technical architecture.

Application Architecture : designs the layered structure, interfaces, and data‑exchange protocols to keep complexity manageable while meeting non‑functional requirements.

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

Data Architecture : standardises data definitions, expressions, and governance to build a unified big‑data platform.

Physical Architecture : maps software components onto hardware, covering data‑center, network topology, servers, and storage.

Operations Architecture : plans, selects, and deploys operational systems and establishes a standardised ops framework.

Typical Application Architecture Patterns

Layered Architecture

Divides the system by responsibilities; a diagram illustrates the classic three‑layer model.

CQRS (Command‑Query Responsibility Segregation)

Separates methods into commands (change state, no return) and queries (return data, no side effects).

Hexagonal (Ports‑and‑Adapters) Architecture

Splits the system into an internal core (business logic) and external adapters that drive or are driven by the core.

Onion Architecture

Extends the hexagonal idea by adding multiple concentric layers such as Application, Domain Service, Domain Model, and Infrastructure, enforcing “outer depends on inner, inner is unaware of outer”.

COLA Open‑Source Application Architecture

COLA is an open‑source framework (https://github.com/alibaba/COLA) that incorporates the above ideas. It refines the classic three‑layer model into four layers: Presentation, Application, Domain, and Infrastructure.

Presentation Layer

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

Application Layer

Handles input validation, assembles context, invokes domain services, and may directly access the Infrastructure layer when needed.

Domain Layer

Encapsulates core business logic via domain services and entities.

Infrastructure Layer

Provides generic utilities, configuration, and a Tunnel abstraction for data sources (databases, search engines, files, SOA services).

Extension Design

For complex scenarios, COLA defines two concepts: Business Identity (a unique BizCode like “ali.tmall.car”) and Extension Point. An Extension Point can have multiple implementations; the combination of Business Identity and Extension Point forms an Extension Coordinate, enabling multi‑tenant and multi‑scenario extensibility.

Specification Design

COLA enforces conventions for module structure, package layout, and naming to reduce randomness and keep the system consistent.

Core Takeaway

The common thread across layered, hexagonal, onion, and COLA architectures is the separation of core business logic from technical details, allowing the domain to evolve independently of infrastructure.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

Design PatternsSoftware ArchitectureCOLACQRSHexagonal Architectureonion architectureextension design
IT Architects Alliance
Written by

IT Architects Alliance

Discussion and exchange on system, internet, large‑scale distributed, high‑availability, and high‑performance architectures, as well as big data, machine learning, AI, and architecture adjustments with internet technologies. Includes real‑world large‑scale architecture case studies. Open to architects who have ideas and enjoy sharing.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.