What Is Software Architecture? Core Concepts, Layers, and Design Principles

What Is Architecture and Its Essence

In the software industry, the term "architecture" is often debated, and different people may have different understandings. Before discussing architecture, it is essential to define the concept, as a shared definition enables effective communication.

Linux, MySQL, and the JVM each have their own architecture, and a business system built with Java on Linux and MySQL also has an architecture. To clarify which architecture to focus on, we need to distinguish several related concepts: system vs. subsystem, module vs. component, and 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 elements cannot do alone.

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

1.2 Module and Component

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

Modules break the system down logically (divide‑and‑conquer) and can vary in granularity—from an entire system, subsystems, services, functions, classes, methods, to functional blocks.

Components may include application services, databases, networks, physical machines, as well as technical components such as MQ, containers, Nginx, etc.

1.3 Framework and Architecture

Frameworks are specifications for implementing components (e.g., MVC, MVP, MVVM) and provide ready‑made functionality (e.g., Ruby on Rails, Spring, Laravel, Django). They are standards; architecture is the structure.

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

Architecture is a systematic, rational decision‑making process that, after weighing trade‑offs within resource constraints, yields the most reasonable solution—a clear system skeleton that includes subsystems, modules, components, their collaboration, constraints, and guiding principles, aligning the whole team’s thinking.

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

Clear system skeleton: explicit composition of the system.

Collaboration relationships among parts to fulfill business requests.

Constraints, standards, 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 reorganize a system in an orderly way to meet current business growth while allowing rapid expansion.

Architecture design is driven by business needs; a system should consider architecture when it has complex requirements, significant non‑functional demands, long lifecycle with extensibility needs, component‑based integration, or requires business process re‑engineering.

Complex requirements.

Important non‑functional requirements.

Long lifecycle with scalability needs.

Component or integration requirements.

Business process re‑engineering needs.

2 Architecture Layers and Classifications

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

2.1 Business Architecture (Strategic)

Encompasses business planning, modules, and processes, breaking down the overall system’s business, and designing domain models that transform real‑world business into abstract objects.

There is no “best” architecture, only the most suitable one that solves business problems; technology‑centric designs that ignore business realities lead to pitfalls.

A reasonable architecture should anticipate business growth for 1‑2 years, balancing cost and benefit.

2.2 Application Architecture (Logical)

Abstracts hardware to applications, defining abstraction layers and programming interfaces. It works hand‑in‑hand with business architecture; each business function maps to an application.

Key points of an application architecture diagram:

Responsibility division: clear boundaries for each logical module or subsystem.

Collaboration: interface protocols (APIs) and interaction relationships between applications.

Application layering can be horizontal (by processing stages such as web front‑end, middle services, background tasks) or vertical (by business domain, e.g., separate inventory, sales, and finance apps).

Application composition reflects how applications cooperate to fulfill complex business cases, influencing communication mechanisms (sync calls, async messages, shared DB) and data formats (JSON, XML, binary).

The goal is to balance business complexity (which drives technical complexity) while keeping the system cohesive.

2.3 Data Architecture

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

2.4 Code Architecture (Development Architecture)

Provides concrete guidance for developers; insufficient code architecture leads to chaotic overall design, especially when different teams use divergent tech stacks.

Key aspects:

Code units: configuration design, frameworks, libraries.

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

2.5 Technical Architecture

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

It focuses on non‑functional characteristics such as high availability, performance, scalability, security, and simplicity.

Designing technical architecture requires deep knowledge of both software and hardware performance.

2.6 Deployment Topology Architecture (Physical Architecture)

Shows how many nodes are deployed, their interconnections, high‑availability setups, network interfaces, and protocols, determining performance, maintainability, and scalability. This view is primarily of interest to operations engineers.