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.
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项修炼》
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Programmer DD
A tinkering programmer and author of "Spring Cloud Microservices in Action"
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
