Understanding Software Architecture: Concepts, Layers, Classifications, and Evolution

1. What Is Architecture and Its Essence

In the software industry, the definition of architecture is often debated; therefore, before discussing architecture, we first clarify its concept, which serves as the basis for communication.

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

1.1 System and Subsystem

System : a group of related entities that operate under certain rules to achieve capabilities that individual components cannot accomplish alone.

Subsystem : a system that is 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 a system into manageable pieces (services, classes, functions, etc.). Components can include services, databases, networks, physical machines, as well as technical components such as MQ, containers, Nginx, etc.

1.3 Framework and Architecture

A framework provides a set of conventions (e.g., MVC, MVP, MVVM) and reusable foundations such as Ruby on Rails, Spring, Laravel, Django, which 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 (subsystems, modules, components) and their collaboration, constraints, and guiding principles, ensuring consistent thinking across the team. It involves four aspects:

Systematic thinking for reasonable decisions (e.g., technology selection, solutions).

Clear system skeleton: which parts compose the system.

Collaboration relationships among parts to fulfill business requests.

Constraints and guiding principles to keep the system orderly, efficient, and stable.

An architect must understand business, have 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; technology evolves only when required by business.

Complex requirements.

Important non‑functional requirements.

Long system lifecycle with scalability needs.

Component‑oriented integration.

Business process re‑engineering.

2. Architectural Layers and Classifications

Architectural classifications can be refined into business architecture, application architecture, technical architecture, code architecture, and deployment architecture.

Business architecture is strategy, application architecture is tactics, and technical architecture provides the equipment. Application architecture bridges business strategy and technology selection.

Understanding business leads to business architecture, which guides appropriate application architecture, and finally technical architecture implements the solution.

2.1 Business Architecture (Top‑down)

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

There is no “optimal” architecture, only the most suitable one that solves business problems efficiently and anticipates future growth.

Complex business volumes and growth trends require architecture that can foresee needs for 1‑2 years, balancing cost and benefit.

2.2 Application Architecture (Logical Architecture)

Abstracts hardware to applications, defining abstraction layers and programming interfaces. It is complementary to business architecture; each business part has a corresponding application architecture.

Key points:

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

Collaboration: interface protocols and inter‑application call relationships.

Application layering can be horizontal (front‑end / middle‑service / back‑task) or vertical (different business domains as independent applications).

Application architecture balances business and technical complexity, ensuring the system remains coherent while supporting growth.

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; insufficient code architecture leads to uncontrolled overall design.

Key definitions:

Code units: configuration design, frameworks, libraries.

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

2.5 Technical Architecture

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

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

2.6 Deployment Topology (Physical Architecture)

Shows node count, relationships, high‑availability setups, network interfaces, and protocols, influencing performance, maintainability, and scalability. This diagram is primarily of interest to operations engineers.

3. Architecture Levels

Using a pyramid model, higher levels contain lower ones:

System level : relationships and governance across the whole system.

Application level : overall architecture of a single application and its interaction with other applications.

Module level : internal module design, data and state management.

Code level : ensuring architectural decisions are enforced in code.

Strategic vs. Tactical Design

Strategic design : business architecture guides how to design system architecture.

Tactical design : application architecture follows business architecture.

Tactical implementation : after application architecture is fixed, technology selection occurs.

4. Application Architecture Evolution

Business architecture is productivity, application architecture is the production relationship, and technical architecture provides the tools. Business architecture determines application architecture, which must adapt as business evolves.

4.1 Monolithic Applications

Simple early‑stage businesses can use a single‑tier application (front‑end, middle‑logic, database) such as a Java Spring MVC or Python Django project.

Typical non‑functional improvements for monoliths include caching, clustering, read/write separation, reverse proxy/CDN, distributed files and databases.

Performance: use cache.

Concurrency: use cluster.

Read/write separation.

Reverse proxy and CDN acceleration.

Distributed file and database.

Drawbacks of monoliths: high complexity, technical debt, low deployment frequency, reliability issues, limited scalability, and hindered innovation.

4.2 Distributed Applications

When business functions become numerous and complex, monoliths become unwieldy. Splitting functionality into services creates a distributed system where each module runs on separate servers and communicates via interfaces.

Benefits: reduced coupling, clear responsibilities, easy expansion, flexible deployment, and higher code reuse.

Drawbacks: increased remote communication overhead.

4.3 Microservices

Complex business scenarios (pricing, promotions, inventory, etc.) require fine‑grained services. Microservices isolate each business capability, enabling independent development, deployment, and scaling.

Advantages: easier development and maintenance, fast startup, localized deployment, technology‑stack independence.

Challenges: higher operational burden, inherent distributed complexity, costly API changes, and potential code duplication across services.

5. Measuring Architectural Reasonableness

Architecture serves business; there is no universally optimal design, only the most suitable one that meets efficiency, stability, and security goals.

5.1 Business‑Driven Criteria

Solves current business problems.

Efficiently fulfills requirements with elegant, reusable solutions.

Forward‑looking design that remains viable for future business evolution.

5.2 Non‑Business Criteria

Stability : high availability through testing, fault injection, and coverage improvement.

Efficiency : documentation, extensibility, and high reuse of existing code and designs.

Security : protect valuable data via encryption, HTTPS, and other standard measures.

6. Common Architectural Pitfalls

Missing critical constraints and non‑functional requirements.

Over‑designing for an imagined future.

Making premature key decisions.

Blindly following client demands.

Lack of foresight while coding.

Neglecting system testability.

Attempting to achieve a perfect architecture in one step.

7. Architecture Knowledge System

7.1 Evolution Stages

LAMP on a single server.

Separate application and data servers.

Introduce caching.

Cluster for concurrency.

Read/write DB separation.

Reverse proxy and CDN.

Distributed file and DB.

Business splitting.

Distributed services.

7.2 Architectural Patterns

Layered (horizontal): presentation, service, data layers.

Segmentation (vertical): split functions and services.

Distributed: applications, static resources, data/storage, computing.

Cluster: improve concurrency and availability.

Cache: performance optimization (CDN, local cache, distributed cache).

Asynchronous: reduce coupling and speed response.

Redundancy: hot/cold backup for high availability.

Automation: CI/CD, testing, monitoring, alerting, failover, recovery.

Security: protect against XSS, SQL injection, CSRF, firewall vulnerabilities, SSL, etc.

7.3 Core Elements

Performance : testing, front‑end optimization, application tuning, DB optimization.

Availability : load balancing, data backup, automated and gray releases, monitoring and alerts.

Scalability : clustering, adding machines quickly.

Extensibility : modular design, open‑closed principle, distributed messaging, service‑oriented design.

Security : defend against attacks, rate limiting, DDoS mitigation.

8. Recommended Architecture Books

"Large‑Scale Website Architecture: Core Principles and Case Studies" – a comprehensive, easy‑to‑understand guide.

"Core Technologies of Billion‑Scale Traffic Websites" – detailed implementation and code examples, including Nginx configuration.

"Architecture Is the Future" – explores the root causes of architectural problems and team management.

"Distributed Service Architecture: Principles, Design, and Practice" – covers design, health, and reliability of online services.

"Talking About Architecture" – discusses architecture origins, business splitting, purpose, and the architect’s role.

"12 Practices for Software Architects" – emphasizes soft skills and how to overcome the so‑called technical glass ceiling.

Copyright Statement: Content is sourced from the internet; all rights belong to the original author. If any infringement is found, please notify us for immediate removal.