What Really Defines Software Architecture? Core Concepts and Layers Explained

1. What is Architecture and Its Essence

In the software industry, there is much debate about what architecture means, and different people have different understandings. Since definitions differ, communication can be difficult, so we first discuss the concept of architecture.

Linux has an architecture, MySQL has an architecture, the JVM has an architecture, and a business system built with Java, MySQL, and running on Linux also has an architecture. Which one should we focus on? To clarify, we need to distinguish several related concepts: system vs subsystem, module vs component, framework vs architecture.

1.1 System and Subsystem

System: a group of related entities that operate according to certain rules and can accomplish tasks that individual components cannot do alone.

Subsystem: also a group of related entities, usually a part of a larger system.

1.2 Module and Component

Both are parts of a system, split from different perspectives. A module is a logical unit, while a component is a physical unit.

A module decomposes the system logically, simplifying complex problems. Its granularity can vary: it can be a system, several subsystems, a service, a function, a class, a method, etc.

A component can include application services, databases, networks, physical machines, as well as technical components such as MQ, containers, Nginx, etc.

1.3 Framework and Architecture

A framework is a specification for implementing components, such as MVC, MVP, MVVM, and provides foundational functionality (e.g., Ruby on Rails, Spring, Laravel, Django). It can be used directly or extended.

Framework is a specification; architecture is a structure.

We define software architecture as the top‑level structure of a software system.

Architecture is the most reasonable decision made after systematic thinking and trade‑offs under resource constraints, defining the system skeleton—including subsystems, modules, components, their collaboration, constraints, and guiding principles—to align the whole team’s thinking. It involves four aspects:

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

Clear system skeleton (identifying system parts).

Collaboration relationships among parts.

Constraints, specifications, and guiding principles to ensure orderly, efficient, and stable operation.

An architect must understand the 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 development and enable rapid expansion.

A system requires architectural design when the business drives the need; architecture evolves based on business demands.

Architecture design is entirely business‑driven. Situations that warrant it include:

Relatively complex requirements.

Significant non‑functional requirements.

Long system lifecycle with extensibility needs.

Component‑based or integration needs.

Business process reengineering.

2. Architecture Layers and Classification

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

Business architecture is strategy, application architecture is tactics, technical architecture is equipment. Application architecture bridges the two: it implements business architecture and influences technology choices.

Understanding the business leads to a business architecture, which informs the application architecture, and finally the technical architecture is implemented.

Choosing the right application architecture for current needs and ensuring smooth future transitions is a key concern for developers and architects.

2.1 Business Architecture (Overview)

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

There is no universally optimal architecture; the most suitable one solves business problems. Architecture not based on business can lead to pitfalls.

Understanding business volume and growth trends helps design architecture that anticipates 1–2 years ahead, balancing cost and business growth.

Example: JD.com business architecture (image).

2.2 Application Architecture (Logical Architecture)

Abstracts hardware to applications, including abstraction layers and programming interfaces. Application architecture complements business architecture; each part of the business architecture has a corresponding application architecture.

Application architecture defines which applications exist and how they cooperate. Applications are independent deployable units that delineate clear boundaries, influencing system functionality, code development, deployment, and operations.

Key points of an application architecture diagram:

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

Collaboration: interface protocols and call relationships between applications.

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

Application collaboration reflects how applications work together via communication mechanisms (synchronous calls, asynchronous messages, shared DB) and data formats (text, XML, JSON, binary).

The goal of application architecture is to balance business complexity and technical complexity, keeping the system cohesive.

2.3 Data Architecture

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 can cause global architectural issues, especially when different teams use different tech stacks.

Code architecture defines:

Code units: configuration design, frameworks, libraries.

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

2.5 Technical Architecture

Determines the actual runtime components (LVS, Nginx, Tomcat, PHP‑FPM, etc.), their relationships, and deployment strategies on hardware.

Technical architecture focuses on non‑functional attributes such as high availability, performance, scalability, security, and simplicity.

Designing system architecture requires deep knowledge of both software and hardware performance, making it one of the most challenging tasks.

2.6 Deployment Topology Architecture (Physical Architecture)

Shows the number of nodes, their relationships, high‑availability setups, network interfaces, and protocols, influencing performance, maintainability, and scalability; primarily of interest to operations engineers.

The physical architecture considers hardware selection, topology, and the mapping between software and hardware.