What Really Defines Software Architecture? Core Concepts and Layers Explained

1. What Is Architecture and Its Essence

In the software industry, the term "architecture" is often debated; a clear definition is essential for effective communication. Architecture is the top‑level structure of a software system, representing a set of rational decisions made under resource constraints that define subsystems, modules, components, and their relationships, constraints, and guiding principles.

1.1 System and Subsystem

System : a group of related entities that operate together according to certain rules to achieve capabilities that individual elements cannot accomplish alone.

Subsystem : a system that functions as a part of a larger system.

1.2 Module and Component

Modules are logical units obtained by decomposing a system, while components are physical units. A module can range from an entire system to a single function or class, whereas a component may include services, databases, networks, physical machines, or technical pieces such as MQ, containers, and Nginx.

1.3 Framework vs. Architecture

Frameworks provide implementation conventions (e.g., MVC, MVP, MVVM) and reusable foundations (e.g., Spring, Django). Architecture, by contrast, is the structural design of the system.

Software architecture is the top‑level structure of a software system, a systematic, trade‑off‑driven decision that defines the system skeleton—including subsystems, modules, components—and their collaboration, constraints, and guiding principles.

Rational decisions through systematic thinking (e.g., technology selection, solution design).

Clear system skeleton: explicit identification of system parts.

Collaboration relationships among parts.

Constraints, standards, and guiding principles to ensure order, efficiency, and stability.

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

The essence of architecture is to reorganize the system orderly to meet current business development and enable rapid expansion.

2. Architecture Layers and Classifications

Architecture can be divided into business architecture, application architecture, data architecture, code (development) architecture, technical architecture, and deployment (topology) architecture.

Business architecture is strategy, application architecture is tactics, technical architecture is equipment. Application architecture bridges business and technical layers.

2.1 Business Architecture (Overview)

Encompasses business planning, modules, processes, and domain‑model design, translating real business into abstract objects. There is no universally optimal architecture—only the most suitable one that solves business problems. A reasonable architecture should anticipate business growth for 1–2 years.

2.2 Application Architecture (Logical)

Abstracts from hardware to applications, defining interfaces and interactions. Each part of the business architecture maps to an application.

Key points:

Responsibility division: clear boundaries of applications (modules/subsystems).

Collaboration: interface protocols and call relationships.

Application layering can be horizontal (by functional flow, e.g., web front‑end → middle services → background tasks) or vertical (by business domain, e.g., separate applications for inventory, sales, finance).

Application architecture balances business complexity with technical complexity, ensuring the system remains cohesive while addressing both concerns.

2.3 Data Architecture

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

2.4 Code Architecture (Development Architecture)

Provides concrete guidance for developers. It defines:

Code units: configuration design, frameworks, libraries.

Code organization: coding standards, module division, top‑level file structure (e.g., MVC), and dependency relationships.

2.5 Technical Architecture

Specifies runtime components (LVS, Nginx, Tomcat, etc.), their relationships, and deployment strategies. It focuses on non‑functional attributes such as high availability, performance, scalability, security, and simplicity.

2.6 Deployment Topology (Physical Architecture)

Illustrates node deployment, relationships, high‑availability setups, network interfaces, and protocols. This topology determines how applications run, their performance, maintainability, and scalability, and is primarily of interest to operations engineers.