What Is Software Architecture? Concepts, Classifications, and Design Patterns

What Is Architecture?

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

Architecture originated from building design; 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 an aircraft to a single e‑commerce component, requires design and architecture.

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

Although some agile ideas advocate “no design, just work,” in reality engineers rarely refactor or optimise code that merely works.

Architect’s Responsibilities

The most important value of an architect is to “simplify complexity.” Any architecture that makes a system more obscure is questionable.

An architect should train their mind to understand complex systems, decompose and abstract them so that designers, implementers, and 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 between them, which are later refined into concrete classes or objects, often via interfaces.

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

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

Software Architecture Classification

With billions of users online, software architectures have become increasingly complex and diverse. The author classifies them as:

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

Application Architecture : Designed by application architects to define layers, interfaces, and data‑exchange protocols while controlling complexity.

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

Data Architecture : Standardises data definitions, expressions, and builds a unified big‑data platform.

Physical Architecture : Concerns hardware placement, network topology, servers, storage, etc.

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

Layered Architecture

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

CQRS

CQS (Command Query Separation) was introduced by Bertrand Meyer. It separates methods into:

Command : Returns no result (void) but changes object state.

Query : Returns a result without changing state, having 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 core (business logic) and external adapters (driving and driven).

Adapters are classified as:

Driving Adapters (active) initiate operations on the application.

Driven Adapters (passive) respond to those operations.

Onion Architecture

Similar to hexagonal, it isolates the core from infrastructure by using adapters, preventing technology lock‑in and allowing easy replacement and testing with mocks.

It adds more layers identified during Domain‑Driven Design (Application, Domain Service, Domain Model, Infrastructure).

Dependency direction is strictly outward: outer layers depend on inner layers, while inner layers are unaware of outer ones.

COLA Application Architecture

COLA is an open‑source application architecture developed by the author’s team, incorporating classic architectural ideas and adding standardized and extensible designs.

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 : Accepts REST requests, routes them to the Application layer, and returns view models (usually DTOs).

Application Layer : Handles input validation, context assembly, invokes domain services, and may directly access infrastructure.

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

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

Extension design introduces two concepts: Business Identity (a unique identifier like a Java package name) and Extension Point. Combining them yields an Extension Coordinate that uniquely determines an extension implementation, enabling multi‑tenant and multi‑scenario customization.

COLA also defines strict conventions for module, package, and naming structures, and adopts port‑adapter (hexagonal) and onion principles to separate core business logic from technical details.

The processing flow uses CQRS to separate commands and queries, and leverages extension points and metadata to enhance extensibility.

The core mission of all discussed architectures—hexagonal, onion, and COLA—is to decouple core business logic from technical details, making the system easier to understand, maintain, and evolve.