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

1. What is Architecture?

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

2. Why Do We Need Architecture?

Any system, from an aircraft to a single e‑commerce feature, requires design and architecture to control complexity, improve understandability, and avoid chaotic code that engineers are reluctant to refactor.

3. Responsibilities of an Architect

An architect’s core value is to simplify complexity, turning intricate systems into understandable structures so designers, implementers, and operators can work with them easily.

Software Architecture

Software architecture is a high‑level sketch of a system, describing abstract components and their connections, which later become 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

Business Architecture : Defined by business architects, influencing organization and technical architecture.

Application Architecture : Designed by application architects to meet business scenarios while controlling complexity and non‑functional requirements.

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

Data Architecture : Provides unified data definition, standardization, and a platform for big‑data processing.

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

Operations Architecture : Plans, selects, and deploys operational systems and standards.

Typical Application Architectures

Layered Architecture : Organises code by responsibilities into presentation, application, domain, and infrastructure layers.

CQRS (Command Query Responsibility Segregation) : Separates commands (state‑changing, no return) from queries (read‑only, return results).

Hexagonal Architecture (Port‑Adapter): Divides the system into an internal core (business logic) and external adapters (driving and driven) to isolate technology details.

Onion Architecture : Similar to hexagonal but adds multiple domain‑driven layers (application, domain service, domain model, infrastructure) and enforces outer‑to‑inner dependency direction.

COLA Application Architecture

COLA is an open‑source framework that adopts classic architectural ideas, adds normative and extensible designs, and uses an archetype to solidify the structure.

Layered Design : Improves the traditional three‑layer model by splitting the business layer into presentation, application, domain, and infrastructure layers.

Extension Design : Introduces "business identity" (BizCode) and "extension points" to allow tenant‑, business‑, and scenario‑specific extensions via an ExtensionCoordinate.

Normative Design : Defines module, package, and naming conventions to reduce randomness and maintain consistency.

Core of Application Architecture

The essential mission is to separate core business logic from technical details, enabling the core to be understandable, reusable, and replaceable while allowing infrastructure to be swapped without affecting the domain.

In summary, architectures such as hexagonal, onion, and COLA share the goal of decoupling business logic from technical concerns, embodying the principle “Give to God what is God’s, and to Caesar what is Caesar’s.”