What Is Software Architecture? Core Concepts, Patterns, and Design Strategies

What is Architecture?

Defining architecture is challenging, but it can be described as an abstract representation of system entities and their relationships.

Architecture originated from building design; as human collaboration grew, systems needed to be divided by principles that enable parallel work across roles.

Why Do We Need Architecture?

Any system, from aircraft to e‑commerce components, requires design and architecture.

A quote from "System Architecture: Product Design and Development for Complex Systems" states that well‑structured creative activity outperforms unstructured effort.

While agile trends sometimes promote "no design," relying solely on working code rarely motivates engineers to refactor or optimize.

Responsibilities of an Architect

An architect’s primary value is to simplify complexity; designs that make systems harder to understand are questionable.

The architect must train their thinking to comprehend complex systems, decompose and abstract them, and create understandable architectures for designers, implementers, and operators.

Software Architecture

Software architecture is a system blueprint describing abstract components and their connections, which later become concrete classes or objects during implementation.

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

The core value of software architecture is controlling complexity, not adhering to a specific layering or methodology.

Software Architecture Classification

Modern internet systems supporting billions of users have diverse architectural styles:

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

Application Architecture : Designs application layers, interfaces, and data contracts while balancing performance, security, and stability.

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

Data Architecture : Standardizes data definitions, governance, and builds unified big‑data platforms.

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

Operations Architecture : Plans, selects, and deploys operational systems with standardized processes.

Layered Architecture

Layering separates responsibilities and organizes code; a typical diagram is shown below.

CQRS

Command Query Separation (CQS) divides methods into commands (no return, change state) and queries (return result, no side effects).

Hexagonal Architecture

Proposed by Alistair Cockburn in 2005, it separates the system into internal (business logic) and external (driving/adapting) parts.

Adapters are classified as:

Driving Adapters (active) initiate actions on the application.

Driven Adapters (passive) respond to the application.

Onion Architecture

Similar to hexagonal, it places the domain core at the center and adds layers (Application, Domain Service, Domain Model, Infrastructure) outward, allowing easy replacement of tools and avoiding lock‑in.

Dependencies flow inward, and inner layers are unaware of outer ones.

COLA Application Architecture

COLA is an open‑source framework developed by Alibaba, combining classic architectural ideas with standardized and extensible designs.

1. Layered Design

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

Layer responsibilities:

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

Application Layer : Handles input validation, composes context, invokes Domain layer, may call Infrastructure directly.

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

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

2. Extensible Design

Introduces Business Identity (BizCode) and Extension Points to uniquely identify extensions, enabling multi‑tenant and scenario‑specific customization.

3. Standardized Design

COLA defines conventions for module structure, package layout, and naming to reduce randomness and improve consistency.

4. COLA Overview

COLA adopts port‑adapter (hexagonal) decoupling, onion‑style domain core, and uses CQRS, extension points, and metadata to enhance extensibility.

The processing flow of a request leverages CQRS, extension points, and metadata, illustrating how commands and queries are handled.

The common theme across all discussed architectures is the separation of core business logic from technical details, enabling maintainability, testability, and flexibility.