What Is Architecture and Its Essence: Definitions, Layers, and Classifications

In the software industry, the definition of architecture is often debated, so this article first clarifies the concept of architecture as the top‑level structure of a software system, a rational decision made after systematic thinking and trade‑offs within resource constraints.

It distinguishes related concepts: a system is a group of interrelated entities that together achieve capabilities none can accomplish alone, while a subsystem is a system that forms part of a larger system.

Modules are logical units obtained by decomposing a system, whereas components are physical units such as services, databases, networks, containers, etc.

A framework provides normative specifications (e.g., MVC, MVP, MVVM) and reusable foundations (e.g., Spring, Django), while architecture is the structural design that guides the whole system.

The article redefines software architecture as the top‑level structure of a software system, representing the most reasonable decision under existing resource constraints, including subsystems, modules, components, their collaboration, constraints, and guiding principles.

Systematic decision‑making (e.g., technology selection, solutions).

Clear system skeleton (identifying all parts).

Collaboration relationships among parts.

Constraints and guiding principles ensuring orderly, efficient, and stable operation.

An architect must understand business, maintain a global view, choose appropriate technologies, solve key problems, and guide implementation.

The essence of architecture is to orderly refactor a system to meet current business needs while allowing rapid expansion.

1. Architecture Layers and Classifications

Architecture can be divided into business architecture, application architecture, technical architecture, code architecture, and deployment architecture.

Business architecture is strategic, application architecture is tactical, and technical architecture provides the equipment.

Understanding business leads to a business architecture, which informs an application architecture, and finally the technical architecture implements it.

1.1 Business Architecture (Strategic)

It includes business planning, modules, and processes, turning real‑world business into abstract models; the best architecture is the most suitable one for solving business problems.

1.2 Application Architecture (Logical)

It abstracts hardware to applications, defining independent deployable units, their responsibilities, boundaries, and collaboration mechanisms (interfaces, protocols, data formats). Application layering can be horizontal (by function) or vertical (by business domain).

1.3 Data Architecture

Guides database design, covering both logical entity models and physical storage considerations.

1.4 Code Architecture (Development Architecture)

Provides concrete guidance for developers, defining code units (configuration, frameworks, libraries) and their organization (coding standards, module division, top‑level file structure, dependencies).

1.5 Technical Architecture

Specifies the actual runtime components (e.g., LVS, Nginx, Tomcat, PHP‑FPM) and their deployment strategies, focusing on non‑functional attributes such as high availability, performance, scalability, security, and simplicity.

1.6 Deployment (Topology) Architecture

Describes the physical nodes, their relationships, high‑availability setups, network interfaces, and protocols, forming the foundation for all other architectures and of primary interest to operations engineers.

Overall, a well‑designed architecture balances business complexity with technical complexity, ensuring the system remains coherent while being adaptable to future growth.