Understanding Software Architecture and the COLA Application Architecture

1. What Is Architecture?

Architecture is an abstract description of the entities in a system and the relationships among them, originating from building design and used to split a target system according to principles that facilitate parallel work by different roles.

2. Why Do We Need Architecture?

Any system, from an aircraft to a single e‑commerce feature, requires architecture to control complexity; a well‑structured design outperforms an unstructured one, and relying solely on "no design" is unrealistic in practice.

3. Responsibilities of an Architect

An architect’s primary value is to simplify complexity, turning intricate systems into understandable structures so that designers, implementers, and operators can work with the system more easily.

Software Architecture

Software architecture is a high‑level sketch of a system, describing abstract components and their connections; it provides a structural, behavioral, and attribute abstraction that links requirements to the system’s organization and guides design decisions.

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

Software Architecture Categories

Business Architecture : Top‑level design that defines business domains and influences organization and technical architecture.

Application Architecture : Designs the application’s layer structure, interfaces, and data‑exchange protocols to keep complexity manageable while meeting non‑functional requirements.

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

Data Architecture : Standardizes data definitions and builds unified big‑data platforms for consistent data assets.

Physical Architecture : Concerns hardware placement, network topology, and various servers.

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

Typical Application Architectures

Layered Architecture : Organizes code by responsibilities into layers (e.g., presentation, application, domain, infrastructure).

CQRS (Command Query Responsibility Segregation) : Separates commands (state‑changing operations) from queries (read‑only operations).

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

Onion Architecture : Extends the hexagonal idea by adding multiple layers (application, domain service, domain model, infrastructure) and enforces dependency direction from outer to inner layers.

COLA Application Architecture

COLA is an open‑source application framework that incorporates classic architectural ideas, adds specification and extension designs, and uses an archetype approach to solidify the architecture for rapid development.

1. Layered Design

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

2. Extension Design

Extension points are defined by a business identity (BizCode) and an extension point; together they form an ExtensionCoordinate that uniquely identifies an extension implementation, enabling multi‑tenant and multi‑scenario extensibility.

3. Specification Design

COLA enforces conventions for module structure, package layout, and naming to reduce ad‑hoc complexity and maintain consistency across projects.

4. COLA Overview

COLA follows the hexagonal and onion principles, using ports‑adapters to decouple technical details and placing the domain at the core; it also adopts CQRS to separate command and query responsibilities, and leverages extension points for flexible customization.

Core of Application Architecture

The common thread across all discussed architectures is the separation of core business logic from technical details, allowing the business core to be understandable, reusable, and replaceable while technical concerns remain interchangeable.