Understanding Software Architecture: Definitions, Layers, and Classifications

In the software industry, the concept of architecture is often debated, so before discussing architecture we first define its meaning as the top‑level structure of a software system.

System vs subsystem: a system is a group of related components that work together to achieve capabilities beyond individual parts; a subsystem is a system that is part of a larger system.

Module vs component: modules are logical units, components are physical units; modules implement divide‑and‑conquer, components include services, databases, networks, containers, etc.

Framework vs architecture: frameworks are specifications or reusable libraries (e.g., MVC, Spring), while architecture is the overall structure.

We define software architecture as the top‑level structure of a software system, a rational decision made after systematic thinking and trade‑offs, describing subsystems, modules, components, their relationships, constraints, and guiding principles.

Systematic decision‑making (technology selection, solutions)

Clear system skeleton (parts composition)

Collaboration relationships among parts

Constraints and guiding principles for orderly, efficient, 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.

Architecture design is driven by business requirements such as complex needs, non‑functional requirements, long lifecycle, component integration, and business process reengineering.

2. Architecture Layers and Classifications

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

Business architecture defines strategy; application architecture translates strategy into deployable units; technical architecture provides the equipment.

2.1 Business Architecture

Includes business planning, modules, processes, and domain model design, turning real‑world business into abstract objects. There is no universally optimal architecture, only the most suitable one for the given business.

2.2 Application Architecture

Describes the abstraction from hardware to applications, defining which applications exist and how they cooperate. It clarifies boundaries, logical layers, subsystems, modules, and key classes, as well as interfaces and collaboration protocols.

Application layering can be horizontal (e.g., web front‑end, middle services, background tasks) or vertical (e.g., separate apps for inventory, sales, etc.).

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, defining code units (configuration, frameworks, libraries), organization (coding standards, module division, top‑level file structure, dependencies).

2.5 Technical Architecture

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

2.6 Deployment Topology

Shows the physical nodes, their connections, high‑availability setups, network interfaces, and protocols; it is the foundation for all other architecture layers and is of primary concern to operations engineers.