Fundamentals 26 min read

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

This article explains the essence of software architecture, covering definitions, system vs. subsystem, module vs. component, framework vs. architecture, various architectural layers, classifications, evolution from monolith to microservices, and how to evaluate a design’s suitability for business and non‑functional requirements.

Programmer DD
Programmer DD
Programmer DD
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; a clear definition is essential for effective communication.

Architecture exists at many levels: Linux, MySQL, JVM, and the business system built on them all have architectures that need consideration.

Key Concepts

System and Subsystem

A system is a group of related components that work together to achieve capabilities beyond individual parts. A subsystem is a system that functions as part of a larger system.

Module and Component

Both are parts of a system; a module is a logical unit, while a component is a physical unit. Modules break down complexity, and components can include services, databases, networks, containers, etc.

Framework vs. Architecture

A framework provides implementation standards (e.g., MVC, Spring) and can be used directly or extended. Architecture, on the other hand, defines the overall structure.

Redefinition of Architecture

Software architecture is the top‑level structure of a software system, a rational decision made after systematic thinking, balancing trade‑offs within resource constraints, and it defines the system skeleton—including subsystems, modules, components, their relationships, constraints, and guiding principles.

Systematic decision‑making (technology selection, solutions)

Clear system skeleton

Collaboration relationships among parts

Constraints and guiding principles for stability, efficiency, and security

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

Architecture’s essence is to orderly refactor a system to meet current business needs while allowing rapid expansion.

Architecture Layers and Classifications

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

Business architecture defines strategy; application architecture translates strategy into concrete designs; technical architecture provides the equipment and implementation details.

Business Architecture (Strategic)

Involves business planning, modules, processes, and domain modeling to turn real‑world business into abstract objects.

There is no “optimal” architecture, only the most suitable one that solves business problems.

Application Architecture (Tactical)

Abstracts hardware to applications, defining boundaries, responsibilities, and collaboration between applications.

Key points: clear responsibility division, logical layering, subsystem/module definition, critical classes, interface protocols, and collaboration relationships.

Application layering can be horizontal (by function) or vertical (by business type).

Data Architecture

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

Code Architecture (Development Architecture)

Provides concrete guidance for developers, defining code units, configuration, frameworks, project module division, top‑level file structure, and dependency management.

Technical Architecture

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

Deployment Topology Architecture

Describes physical nodes, their relationships, high‑availability setups, network interfaces, and protocols, which are primarily of interest to operations engineers.

Architecture Levels

System Level : relationships and governance across the whole system.

Application Level : overall architecture of a single application and its interaction with the system.

Module Level : internal module structure, code modularization, data and state management.

Code Level : ensuring implementation aligns with architectural intent.

Strategic vs. Tactical Design

Strategic Design : Business architecture guides system design.

Tactical Design : Application architecture is derived from business architecture.

Tactical Implementation : Technical architecture realizes the application design.

Evolution of Application Architecture

Business architecture drives application architecture, which in turn adapts to technical architecture.

Evolution path: Monolith → Distributed Services → Microservices.

Monolith

Suitable for simple early‑stage business; typical three‑tier structure (frontend, business logic, database). However, as complexity grows, monoliths become hard to maintain, scale, and deploy.

High complexity and technical debt

Low deployment frequency

Poor reliability

Limited scalability

Hinders innovation

Distributed

Business modules are split into separate services, reducing coupling, clarifying responsibilities, and improving scalability.

Lower coupling

Clear responsibilities

Easy expansion

Convenient deployment

Improved code reuse

Microservices

Each microservice focuses on a specific business function, enabling fast development, independent deployment, and technology‑stack flexibility, while introducing operational complexity and distributed challenges.

Easy development and maintenance

Fast startup

Independent deployment

Technology‑stack freedom

Measuring Architecture Reasonableness

There is no “optimal” architecture, only the most suitable one that meets efficiency, stability, and security goals.

Business‑Driven Criteria

Solves current business problems effectively.

Provides elegant, reusable solutions.

Offers forward‑looking design to accommodate future evolution.

Non‑Business Criteria

Stability : High availability through testing, fault injection, and coverage.

Efficiency : Documentation, extensibility, and reusability.

Security : Data protection, encryption, HTTPS, etc.

Common Architecture Pitfalls

Missing key constraints and non‑functional requirements.

Over‑designing for an uncertain future.

Making premature critical decisions.

Relying solely on stakeholder demands.

Lacking foresight and measurability.

Attempting to design a perfect architecture in one step.

Architecture Knowledge System

Includes evolution stages, patterns (layered, vertical split, distributed), clusters, caching, asynchronous communication, redundancy, automation, and security measures.

Recommended Books

《大型网站技术架构:核心原理与案例分析》

《亿级流量网站架构核心技术》

《架构即未来》

《分布式服务架构:原理、设计与实战》

《聊聊架构》

《软件架构师的12项修炼》

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

Software ArchitectureMicroservicesSystem Designmonolithdesign principles
Programmer DD
Written by

Programmer DD

A tinkering programmer and author of "Spring Cloud Microservices in Action"

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.