Why Architecture Matters: From Basics to the COLA Framework

Architecture lacks a single standard definition; it can be described as an abstract representation of system entities and their relationships.

1. What is Architecture?

Architecture originated from building design and emerged to support division of labor, allowing different roles to work in parallel by splitting a system according to guiding principles.

2. Why Architecture?

Every system, from aircraft to a single e‑commerce feature, needs architecture. A well‑structured creation outperforms a chaotic one, yet pure “no design” agile ideas are unrealistic because engineers rarely refactor code without clear incentives.

3. Architect’s Responsibilities

The architect’s core value is to simplify complexity, turning opaque systems into understandable ones for designers, implementers, and operators.

Software Architecture

Software architecture is a high‑level abstraction of a system’s components and their interactions, later refined into concrete classes or objects. It defines structure, behavior, and attributes, linking requirements to system organization and providing design decision principles.

Software Architecture Classification

Key categories include:

Business Architecture – top‑level design influencing organization and technical architecture.

Application Architecture – defines layers, interfaces, and non‑functional requirements.

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

Data Architecture – standardizes data definitions, governance, and big‑data platforms.

Physical Architecture – maps software components to hardware, networks, and servers.

Operations Architecture – plans, selects, and deploys operational systems.

Typical Application Architectures

1. Layered Architecture

Divides the system by responsibilities; a diagram (not shown) illustrates common layers.

2. CQRS

Command‑Query Separation separates methods that change state (commands) from those that return data without side effects (queries).

3. Hexagonal Architecture

Also called Port‑Adapter architecture, it separates the core business logic (inner hexagon) from external drivers and infrastructure (outer adapters), distinguishing driving and driven adapters.

4. Onion Architecture

Similar to hexagonal but adds multiple layers (Application, Domain Service, Domain Model, Infrastructure) to avoid technology leakage into the core.

COLA Application Architecture

COLA is an open‑source framework that incorporates classic architecture ideas, adds normative and extension designs, and uses an archetype to solidify the structure.

1. Layered Design

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

2. Application Layer

Handles input, context assembly, validation, invokes domain services, and may send notifications; it can also directly access infrastructure when needed.

3. Domain Layer

Encapsulates core business logic via domain services and entities.

4. Infrastructure Layer

Provides tunnels for data sources (databases, search, files, SOA services), configuration, and common utilities.

2. Extension Design

Introduces “business identity” (BizCode) and “extension points” to uniquely identify extensions, enabling multi‑tenant and multi‑scenario customization.

3. Normative Design

Defines conventions for modules, packages, and naming to reduce randomness and maintain consistency across the architecture.

4. COLA Architecture Overview

Combines hexagonal and onion principles: ports‑adapters decouple technical details, while domain‑centric layers enforce dependency inversion, resulting in a component relationship diagram (not shown).

Core of Application Architecture

The central mission is to separate core business logic from technical details, allowing the former to reflect domain models clearly and the latter to be replaceable, summarized by the principle “Give to God what is God’s, give to Caesar what is Caesar’s.”