Understanding Software Architecture: Definitions, Layers, and Classifications

1. What Is Architecture and Its Essence

In the software industry, the definition of architecture is often debated; this article first clarifies the concept of architecture as the top‑level structure of a software system, a systematic decision made under resource constraints that defines the system skeleton, including subsystems, modules, components, their collaboration, constraints, and guiding principles.

Architecture exists at many levels: Linux, MySQL, JVM each have their own architecture, and a business system built with Java, MySQL, running on Linux also has an architecture.

1.1 System and Subsystem

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

Subsystem: a system that is part of a larger system.

1.2 Module and Component

Both are parts of a system; a module is a logical unit, while a component is a physical unit.

Modules decompose a system logically (e.g., services, classes, functions), whereas components can include services, databases, networks, physical machines, MQ, containers, Nginx, etc.

1.3 Framework and Architecture

Frameworks are specifications for implementing components (e.g., MVC, MVP, MVVM) and provide reusable foundations such as Ruby on Rails, Spring, Laravel, Django.

Framework is a specification; architecture is a structure.

Software architecture is defined as the top‑level structure of a software system, a rational decision after systematic thinking and trade‑offs, resulting in a clear system skeleton that guides the whole team.

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

Clear system skeleton (identifying parts).

Collaboration relationships among parts.

Constraints, specifications, and guiding principles for 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 reorganize a system orderly to meet current business needs while allowing rapid expansion.

2. Architectural 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.

2.1 Business Architecture (Overview)

Includes business planning, modules, processes, and domain model design, turning real business into abstract objects.

There is no universally optimal architecture; the most suitable one solves business problems and anticipates future growth.

2.2 Application Architecture (Logical Architecture)

Abstracts from hardware to applications, defining clear boundaries for deployable units, influencing system functionality, code development, deployment, and operations.

Key aspects:

Responsibility division: logical layering, subsystem/module definition, key classes.

Collaboration: interface protocols and interaction relationships.

Application layering can be horizontal (e.g., web front‑end, middle services, background tasks) or vertical (e.g., separate applications for different business domains).

2.3 Data Architecture

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

2.4 Code Architecture (Development Architecture)

Provides concrete guidance for developers; insufficient code architecture leads to chaotic overall design.

Defines code units (configuration, frameworks, libraries) and their organization (coding standards, module division, top‑level file structure, dependencies).

2.5 Technical Architecture

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

2.6 Deployment Topology (Physical Architecture)

Shows node deployment, relationships, high‑availability, network interfaces, and protocols, forming the basis for operations and maintenance.

The physical architecture considers hardware selection, mapping of software to hardware, and their mutual influence.

---

Technical Learning Community

"Architecture Master" has created a reader group; add my WeChat to join.

Add a note with "City+Position+Experience" when joining.